über .Net nörgeln

Knuddlbaer

Nun, die Kritik bezieht sich, wenn auch vllt. etwas überzogen, IMHO auf die Tatsache, das .Net sehr nahe an Windows gebaut ist. Sollte es doch Plattformübergreifend sein, findet man sehr viele parallelen zur WinAPI.

Vergessen sollte man hier jedoch nicht das Project Mono - was zwar die Möglichkeit eröffnet auf Windowsfremden Plattformen zu arbeiten aber die komplette Plattformunabhängigkeit (noch) nicht bieten kann.

Warum man unbedingt Dateiendungen benötit verstehe ich ohnehin nicht. Es gibt genug Systeme, die völlig ohne Endung auskommen um den betroffenen Typ und die damit auszuführende Aktion zu ermitteln.

Auch wenn der Post des Ops etwas sachlicher hätte sein können, sind es doch Posts wie die vor diesem, die das ganze von einer Diskussion zum Offtopic treiben. Dabei finde ich persönlich das Thema garnicht mal so uninteressant - erst recht wenn z.B. husbear noch ganz andere Aspekte einbringen könnte - sofern das hier bis dahin nicht völlig zum Offtopic und eher was für NADRW mutiert.

Krux

Talla schrieb:

Krux schrieb:

Gut der moderne Mensch ist ja von Natur aus neugierig, und probiert einfach mal aus ein C# Programm zu kompilieren. Aber was ist das, hat doch tatsächlich das .Net programm die Endung .exe.

Und? Ich frag mich echt was für eine Langeweile man haben muss um sich über Dateiendungen aufzuregen. Die Datei die rauskommt ist eine ausführbare Datei die du für Windows kompiliert hast und auch den gleichen Aufbau hat wie jede andere *.exe Datei, sie wird sogar durch den gleichen Mechanismus gestartet von Windows. Eine andere Endung zu wählen wäre die falsche Entscheidung.

also das Stimmt definitiv nicht, .NET ist eine Plattform ähnlich wie die von Java, damit sie unabhängig sein kann, es halndelt sich hierbei also um eine Virtuelle Maschiene. Unter Linux tritt nur dann das Problem auf, dass wenn man alle .NET projetke mit mono starten möchte, dann geht das einfach nicht, weil sich .NET anwendungen einfach nicht eindeutig identifizieren lassen(jedenfalls nicht mit der Endung), im gegensatz zu den Java Programmen.

zwutz

Knuddlbaer schrieb:

Warum man unbedingt Dateiendungen benoetit verstehe ich ohnehin nicht. Es gibt genug Systeme, die voellig ohne Endung auskommen um den betroffenen Typ und die damit auszufuehrende Aktion zu ermitteln.

Ich find die Methode MIT Endungen sogar besser als ohne... so erkennt man auf einem Blick, WAS die Datei macht. Unter Linux seh ich bei einem einfachen Dateilisting nichtmal, ob das nun Dateien oder Verzeichnisse sind, geschweige denn, was denn nun eine Text-Datei oder ne ausfuehrbare Datei ist

Da das der Nörgel Thread ist geb ich auch mal was dazu.

Einer meiner wenigen Kritikpunkte an .Net (ab 2.0) ist der Indexoperator in den .Net Collections. Kann einfach nicht verstehen warum der einen signed parameter nimmt.

Btw. wieso ist die Syntax eigentlich so komisch oder kommt das nur mir so vor

class  Test
{
   public int this[uint id]
   {
      return ...;
   }
}

Knuddlbaer

zwutz schrieb:

Ich find die Methode MIT Endungen sogar besser als ohne... so erkennt man auf einem Blick, WAS die Datei macht. Unter Linux seh ich bei einem einfachen Dateilisting nichtmal, ob das nun Dateien oder Verzeichnisse sind, geschweige denn, was denn nun eine Text-Datei oder ne ausfuehrbare Datei ist

Was erkenne ich an Secret.exe denn genau ? Was wenn ich Secret.exe und Secret.com in einem Verzeichnis habe ? Was sagt mir die Endung denn ?!

Wird eine Textdatei, die man Secret.exe nennt denn ausführbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei ?

Kann einfach nicht verstehen warum der einen signed parameter nimmt.

Wird der Indexer nicht durch die Schnittstelle festgelegt ? Diese kann nicht wissen ob der erbende nicht mit negativen Indexen arbeiten will und wird daher nicht uint vorgeben können. Du könntest ja eine Liste implementieren wollen, die Elemente vom Index -50 bis 49 hält.

Knuddlbaer schrieb:

Wird eine Textdatei, die man Secret.exe nennt denn ausführbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei ?

Einspruch: "Polemik"

Knuddlbaer schrieb:

Du könntest ja eine Liste implementieren wollen, die Elemente vom Index -50 bis 49 hält

Ja und eine die was anderes benutzt. Dann hätte man korrekter Weise object als Indextyp nehmen sollen.

zwutz

Knuddlbaer schrieb:

Was erkenne ich an Secret.exe denn genau ? Was wenn ich Secret.exe und Secret.com in einem Verzeichnis habe ? Was sagt mir die Endung denn ?!

Wird eine Textdatei, die man Secret.exe nennt denn ausfuehrbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei?

Dateilisting unter Windows:

bar\
blubb.exe
foo.txt
command.com

unter Linux:

bar
blubb
foo
command

man erkennt sofort, welche Dateien welchen Zweck erfuellen... Man kann Endungen bestimmten Anwendungen zuordnen, mit der sie geoeffnet werden sollen (.cvs und .txt sind beides reine Textdateien, erstere wuerd' ich aber nie mit notepad und letztere nie mit Excel oeffnen) und ausserdem ist in Filelistings eine einfache Filterung nach gewuenschten Dateitypen moeglich.

Darueber hinaus sind Dateiendungen fuer den Betrieb vieler Anwendungen zwingend erforderlich (auch ein Compiler geht nach Dateiendungen)

Vorden

also irgendwann gabs mal die Diskussion um Dateiendungen schon
und afaik gabs da auch mal einen kleinen Glaubenskrieg von den vermeintlich "Großen" zu dem Thema
ich denk, da kann man sich jetz auch lange drüber streiten, ob eine Dateiendung sinnvoll ist oder nicht
Aber ich denke, dass das .NET-Framework ja noch ein wenig mehr zu bieten hat, als *.exe-Dateien in binärer Form (oder halb-binär).

zwutz schrieb:

Knuddlbaer schrieb:

Was erkenne ich an Secret.exe denn genau ? Was wenn ich Secret.exe und Secret.com in einem Verzeichnis habe ? Was sagt mir die Endung denn ?!

Wird eine Textdatei, die man Secret.exe nennt denn ausfuehrbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei?

Dateilisting unter Windows:
bar\
blubb.exe
foo.txt
command.com
unter Linux:
bar
blubb
foo
command
man erkennt sofort, welche Dateien welchen Zweck erfuellen... Man kann Endungen bestimmten Anwendungen zuordnen, mit der sie geoeffnet werden sollen (.cvs und .txt sind beides reine Textdateien, erstere wuerd' ich aber nie mit notepad und letztere nie mit Excel oeffnen) und ausserdem ist in Filelistings eine einfache Filterung nach gewuenschten Dateitypen moeglich.

Darueber hinaus sind Dateiendungen fuer den Betrieb vieler Anwendungen zwingend erforderlich (auch ein Compiler geht nach Dateiendungen)

du hast nicht verstanden, was knuddelbär gesagt hat

zwutz

typischtroll schrieb:

du hast nicht verstanden, was knuddelbaer gesagt hat

dann sag du es mir doch

Was man gerne hat:
Typen für Dateien, wegen der genannten Vorteile.

Was man nicht gerne hat:
Den Typ im Dateinamen kodiert.

Windows mach beides.
Linux keines (Flag für ausführbar zählt nicht)
Ein Dateisystem mit Datei typen als "Metadata" oder so ähnlich gibt es meines Wissens nicht (Warum eigentlich?)

Back to .Net Nörgeln

sothis_

zwutz schrieb:

typischtroll schrieb:

du hast nicht verstanden, was knuddelbaer gesagt hat

dann sag du es mir doch

das war kein troll. das war nur ich von einem anderen rechner. seit wann gibt dir die dateiendung garantie über den inhalt? ist schon toll das windows alles nach endung überprüft und entprechende programme nach doppelklick dann schön abstürzen weil der inhalt nicht zur dateienddung passt
unter unix-derivaten gibt es übrigens ein schönes tool names file. ein, zwei zeilen bashscript, und ich kann wesentlich verlässlicher dateien nach inhalt auflisten, als es mit diesen schwachsinnigen dateiendungen möglich ist.

Knuddlbaer

Man Dateiendungen wollte ich hier nicht diskutieren. Aber gut, kurzer Ausflug.

Unter Linux zeigst Du uns die einfache Auflistung eines Verzeichnisses. Dann verwende auch bitte unter Windows die einfache Version (/B)

C:\t\test>dir /b
datei
verzeichnis

Beim Verzeichnis gibt es - zumindest bei mir unter cmd - kein \

bar\
blubb.exe
foo.txt
command.com

Alles was ich da sehe: Eine Datei namens blubb.exe , foo.txt und command.com . Ob command.com nun ausführbar ist oder eine Textdatei ist, sieht man an diesem Listing nicht.

Mein guter alter Amiga A500 konnte auch Anwendungen Dateitypen zuordnen, ganz frei von Dateiendungen. Hierzu wurde einfach der Header der Datei analysiert und zugeordnet. Dateiendungen sind schlicht nicht zwingend erforderlich. (Kurzum: Wenig Rechenleistung, keine Dateiendungen, kein Veralbern von Anwendern in dem man einfach eine Datei umbenannte.)

Wie aber gesagt wurde, gab es diesen Glaubenskrieg bereits und hier möchte ich viel mehr Probleme mit dem Framework diskutieren , nicht alte Glaubenskriege ausgraben. Oder diesen bitte in einem neuen Thread anzetteln.

Collections, die als Positionsangabe ein object entgegen nehmen nennen sich z.B. Dictionary.

Würde für einen numerischen Index ein object verwendet, hättest Du massig Nachteile durch (un|%)boxing. Dies durch ein Interface erzwungen bedeutet massig Performanceverlust für alle folgenden Klassen.

Diese Ansicht stellt eine Möglichkeit dar, warum viele Collections einen int nehmen. Möglich wäre es auch, das die Entwickler zu faul waren uint zu schreiben weil int einfach sitzt. Die genauen Gründe kennen wohl nur die Designer.

Ja und eine die was anderes benutzt. Dann hätte man korrekter Weise object als Indextyp nehmen sollen.

Polemik ?

zwutz

auch von mir die letzte Antowrt zu dem Thema

bei command.com sieht man tatsaechlich nicht, ob es nun ausfuehrbar oder eine Textdatei ist (genausowenig wie bei command). Aber man sieht, dass wahrscheinlich versucht wird, sie auszufuehren.

Und die Moeglichkeit ueber die Dateiheader gibt es auch, aber das erfordert zumindest Leserechte um zu wissen, was mit der Datei geschieht... und natuerlich muss die Datei geoeffnet werden... bei einem Verzeichnis mit mehreren hundert Dateien alle erstmal zu oeffnen, nur um sie danach wieder auszufiltern erscheint mir aber ein wenig ineffizienter als ein reines Filtern nach .xxx am Ende des Dateinamens
Noch dazu haben Textdateien keinen Dateiheader, obwohl wie gesagt eine csv-Datei niemand mit einem Texteditor oeffnen will...

hustbaer

templäd schrieb:

Da das der Nörgel Thread ist geb ich auch mal was dazu.

Einer meiner wenigen Kritikpunkte an .Net (ab 2.0) ist der Indexoperator in den .Net Collections. Kann einfach nicht verstehen warum der einen signed parameter nimmt.

Btw. wieso ist die Syntax eigentlich so komisch oder kommt das nur mir so vor
class  Test
{
   public int this[uint id]
   {
      return ...;
   }
}

Der Grund ist AFAIK dass das Common Type System nicht vorschreibt dass eine Sprache unsigned Typen unterstützen muss.

Talla

EDIT: Mist zu lang zum schreiben gebraucht

Diese Ansicht stellt eine Möglichkeit dar, warum viele Collections einen int nehmen. Möglich wäre es auch, das die Entwickler zu faul waren uint zu schreiben weil int einfach sitzt. Die genauen Gründe kennen wohl nur die Designer.

*lol* Interessante Gedanken, aber stimmen leider nicht
Die wissen schon warum sie das gemacht haben.

Um die Menge an verfügbaren und zukünftigen .Net Sprachen unter einem Hut zu bringen, muss eine bestimmte Menge an Funktionalität vorgeschrieben werden, dass sprachübergreifend problemlos zusammengearbeitet werden kann. Dafür gibts die CLS (Common Language Specification). Was dort drin steht muss eine Sprache erfüllen um als .Net kompatibel zu gelten.

Unsigned Datentypen gehören nicht dazu! Deshalb darf in der Klassenbibliothek überhaupt nie irgendwo unsigned ... verwendet werden, da sonst nicht garantiert wäre dass die Klasse mit allen .Net Sprachen benutzt werden kann. Somit erledigt sich die Frage warum IList einen signed Integer verwendet und nicht ein unsigned.

Einem selber steht es natürlich frei auch Indexer mit anderen Datentypen zu implementieren, aber kompatibel zu allen Sprachen wird das nur bedingt.

Und für eine Liste mit numerischen Index object als Indextyp zu verwenden ist doch unsinnig. Wie Knuddelbaer sagt, da gibts Dictionaries die Schlüssel/Wert Paare speichern.

Danke für die Info!
CLS enthält keine unsigned typen !wichtig! werd ich mir merken.
Über die eigenartige Syntax zur Definition eine [] operators kann ich hinwegsehen.

Ansonsten scheint es mir so als gäbe es nicht so viel zu Nörgeln oder?
Ich überlege noch ein bißchen.

asc

Also über die Dateiendung zu nörgeln finde ich auch schon fehl am Platz, da die Technologie nun mal von der MS-Plattform ausgeht wo sie bislang immer Standard war. Zumindestens kann ich dies nicht .Net anlasten.

Ich bin jetzt nicht von .Net 100%ig überzeugt, muss aber dennoch sagen das mir viele Ansätze im .Net (gerade ab den .Net Framework 3.0; ins Besondere WPF, WCF...) sehr zusagen. Das Problem mit dem Monopolist sehe ich durchaus, aber ich bewerte eine Programmierumgebung mehr nach der Handhabung als nach dem Namen der dahinter steckt). Eine höhere Portabilität und Standardisierung fände ich auch gut, und ich hoffe das Mono weitgehend nachziehen kann (wobei ich nicht damit Rechne das z.B. WPF kurzfristig portiert wird - wobei dies mit OpenGL-Mitteln wohl auch machbar sein dürfte).

cu André

simon.gysi

Knuddlbaer schrieb:

Nun, die Kritik bezieht sich, wenn auch vllt. etwas überzogen, IMHO auf die Tatsache, das .Net sehr nahe an Windows gebaut ist. Sollte es doch Plattformübergreifend sein, findet man sehr viele parallelen zur WinAPI.

Vergessen sollte man hier jedoch nicht das Project Mono - was zwar die Möglichkeit eröffnet auf Windowsfremden Plattformen zu arbeiten aber die komplette Plattformunabhängigkeit (noch) nicht bieten kann.

Bei .NET war eines der Ziele Sprachunabhängigkeit, nicht die Platformunabhängigkeit.

Gruss Simon

Krux

zur Java JRE gabs auch andere Sprachen, wie zum beispiel Groovy. Aber produktiv arbeiten kann man damit schon, auch wenn es unter Linux dazu doch etwas einrichtungszeit benötigt, weil .NET eben nicht alles bietet, um Plattformunabhängig zu sein. Genannt habe ich die dinge schon, die Probleme verursachen, wie zum Beispiel dass sich .NET auf wildows DLLs stützt, die unter Linux einfach nicht verfügbar sind. Aber wenn es sich doch noch um DLLs handelt, die als lib.so unter Linux vorhanden sind, dann haben die einen anderen namen, was dazu führt, das sie ohne weiteres nicht gefunden werden. Vieles, was auf Windows sehr sauber aussieht, wird damit unter Linux zu einer unschönen Frickelei. Die Dateiendung .exe stört deshalb, weil ich unter linux gerne meine Mono programme eindeutig identifiziert haben möchte, damit ich sie in verbindung mit der mono plattform Bringen kann, das geht aber nicht, weil es auch noch Programm gibt, die die endung .exe haben, allerdings mit wine gestartet werden sollen. Ansonsten ist mir die Endung ziemlich egal, sie soll ihren Zweck als Typ-Identifizierung übernehmen, was sie hier allerdings nicht mehr kann.

Zur Diskussion, dass man eine Dateiendung einfach ändern kann, was dazu führt, dass die Dateien mit den falschen Anwendungen geöffnet werden. Sollte der Dateityp im Header Stehen, wer sollte einen Anwender daran hindern, den Header zu ändern? So kann man auf die gleichen Fehler kommen. Die beiden Arden den Typ einer Datei festzustellen sind somit gleichwertig. Die einzige sicherheitslücke ist es die dateiendungen ausblenden zu lassen, denn so sieht eine Wichtig.pdf.exe wie ein harmloses dokument aus, kann sich aber als ein gefährlicher Virus entpuppen. Aber wer stellt schon die Dateiendungen ab? Ich hoffe hiermit ist die Diskussion über Dateiendungen endgültig erledigt.