.NET und C# Pro und Contra

[noxon]

Re: Paint.NET als Alternative zu Microsoft Paint

3200 Codezeilen in C# -> 64kb bei der .exe
Die RE hat <25MB

Genau so ist es. Da hat sich wohl wieder einer nicht richtig informiert.
Manchmal bin ich selbst völlig von den Socken, wie klein die .NET Programme sind.

Für die Beta der einzelnen IDE's (Visual C# Express 2005,Visual Basic Express 2005) musst du kein MSDN-Account haben. Den brauchst du nur für die Beta vom kompletten VS'05.

Oh Danke. Das hatte ich nicht gesehen. *download*

 

[Siberian..Husky]

Re: Paint.NET als Alternative zu Microsoft Paint

3200 Codezeilen in C# -> 64kb bei der .exe
Die RE hat <25MB

ich rede von programmen die auch was tun. paint.net ist 2.5mb groß. auf ner diskette wird man auch bei .net programmen nicht viel unterbringen können. aber immerhin wohl mehr als bei java.

bei den usb sticks kann man sich ja streiten, aber meiner hat eben nur 32mb. da wird es also schon knapp bei den 24mb der .net runtime...

 

[noxon]

Paint.NET hat ja auch nur eine 4MB große Hilfe-Datei. *Kopfschüttel*

Ich glaube für mich ist jetzt auch der Zeitpunkt gekommen mich aus dieser Diskussion zurückzuziehen. Hat ja keinen Sinn.

 

[Siberian..Husky]

so sicher nicht. das ich bei 2.5mb die 4mb hilfe schon abgezogen habe ist doch wohl klar, oder?

 

[CFI]

Hab mal Kurz durchgezählt:
Paint.net hat 34872 Codezeilen wo die .cs-Files alleine 1.82MB haben. Die Daraus erstellte .exe hat "nur" 1.1MB.
Den Code der Restlichen .dll's und der Icons o.ä. in der .exe nicht mitgezählt.

 

[CapFuture]

ehm mit file-größe zu argumentieren ist bissel doof... um da objektiv zu sein müsste man noch das .Net Framework dazutun und dann fängt das theater wieder an...

Also lasst DIESEN vergleich bei seite, es gibt noch genügend andere punkte

Das MS aus seinem selbstgemachten DLL schlammasel raus will, ist löblich.
Aber wenn man will, kann man dies auch ohne .Net schaffen (siehe Firefox, etc.)

Vom Argument "Heutzutage haben alle xyz Ghz, CPU Cyklen sind billig" halte ich im allg. auch nix. Wenn du an deutschen Schulen gehst, wirste haufenweise rechner <500 Mhz finden die alle aktiv gebraucht werden.
Wenn man .Net wirklich verbreiten möchte, so muss es für die Schulen/Lehrer attraktiv werden. Mir ist bewusst, dass Lehrer bestenfalls 10% soviel wissen wie ein Schüler und davon bestenfalls die hälfte richtig ist, aber man kann schlecht auf nem 233er P2 mal ein .Net programm vorstellen... Java geht da noch, aber wird bei etwas komplexeren Programmen auch schon zur qual.
Da hilft es auch nicht, dass das Programm beim 2. oder 3. mal schnell läuft, dafür aber den Ram vollschreibt...

Man merkt, ich bin weder .Net'ler noch Java freund, wobei ich schon nette sachen mit Java erlebt habe
Tatsache ist leider, das es im moment keine Sprache gibt, die alle glücklich macht.

C/C++ <-- Teilweise doch schon betagt (einfaches Bsp. Strings), schnell, für Zeitkritische anwendungen tauglich
Java <-- modern, sehr leicht portierbar, langsam, defizite in der GUI, (GC)
C# <-- modern, effizienteres verhalten (Von MS für MS), nicht wirklich portierbar

Was bleibt ist die erkenntnis, dass man immer das nehmen sollte, was das problem schnell (programmiertechnisch) und effizient für eine bestimmte zielgruppe löst. Alles kann man leider nicht haben...

 

[CFI]

Das MS aus seinem selbstgemachten DLL schlammasel raus will, ist löblich.
Aber wenn man will, kann man dies auch ohne .Net schaffen (siehe Firefox, etc.)

Ein musst du aber noch beachten:
Bei .net hast du den Vorteil das du keine Systemabhängige-Registry hast und deshalb Programme einfach kopieren kannst UND den Vorteil einer Registry wo du PC-Abhängige Werte abspeichern kannst. Ohne .net und Registry musst du auf eines der beiden Verzichten.

Vom Argument "Heutzutage haben alle xyz Ghz, CPU Cyklen sind billig" halte ich im allg. auch nix. Wenn du an deutschen Schulen gehst, wirste haufenweise rechner <500 Mhz finden die alle aktiv gebraucht werden.
Wenn man .Net wirklich verbreiten möchte, so muss es für die Schulen/Lehrer attraktiv werden. Mir ist bewusst, dass Lehrer bestenfalls 10% soviel wissen wie ein Schüler und davon bestenfalls die hälfte richtig ist, aber man kann schlecht auf nem 233er P2 mal ein .Net programm vorstellen... Java geht da noch, aber wird bei etwas komplexeren Programmen auch schon zur qual.
Da hilft es auch nicht, dass das Programm beim 2. oder 3. mal schnell läuft, dafür aber den Ram vollschreibt...

Wir haben in der Schule auch 333MHz Rechner und mit denen lässt sich wunderbar .net programmieren und ausführen.

 

[CapFuture]

Naja, MacOS löst das Problem, indem es das Programm mit "DLLs" in einem Ordner mit Autostartfunktion kapselt und die Konfigfiles (reine textfiles) in einem standardsystemordner hinschmeißt.
Dies muss doch auch mit Windows möglich sein und .Net scheint hier wohl in die richtige Richtung zu gehen...

.Net auf 333er? Da streit ich mich nicht drüber, ich hab auch Win2k auf nem 486er installiert und es lief

 

[CFI]

Naja, MacOS löst das Problem, indem es das Programm mit "DLLs" in einem Ordner mit Autostartfunktion kapselt und die Konfigfiles (reine textfiles) in einem standardsystemordner hinschmeißt.
Dies muss doch auch mit Windows möglich sein und .Net scheint hier wohl in die richtige Richtung zu gehen...

Also ich find die Lösung von .net super. Da hatt, einfach gesagt, jede .exe ihrer eigene Registry, welche direkt in der .exe gespeichert wird und so beim kopieren der .exe mitkopiert wird.

.Net auf 333er? Da streit ich mich nicht drüber, ich hab auch Win2k auf nem 486er installiert und es lief

Das war ernst gemeint. 333MHz mit Win2k wobei nur das OS lokal ist. Das erstellen der .exe geht nicht so schnell, aber sonst läuft es nicht schlechter als auf meinem 2500+. Sogar PDA-Emulationen mit WinMobile2k3 laufen da "flüssig".

 

[CapFuture]

333er und win2k geht, weiß ich... nur irgendwann haste keine freude mehr...
Und wie gesagt, .Net geht im bereich Windowsprogrammierung in die richtige richtung, auch wenn ich mit GC & Co. nicht zufrieden bin/sein werde.

 

[Siberian..Husky]

Ein musst du aber noch beachten:
Bei .net hast du den Vorteil das du keine Systemabhängige-Registry hast und deshalb Programme einfach kopieren kannst UND den Vorteil einer Registry wo du PC-Abhängige Werte abspeichern kannst. Ohne .net und Registry musst du auf eines der beiden Verzichten.

und in c++ programmen kann man keine xml dateien schreiben oder die registry benutzen? oder sogar beides?

auch die betagten strings kann ich nicht verstehen. was ist an std::string so viel complizierter als bei java (mit c# hab ich noch nie gearbeitet)? ausserdem gibts wiegesagt ja etliche andere bibliotheken. QString aus der Qt kann alles was man mit einem string tun können muss, und ist dabei noch schneller als std::string von ms und stlport(andere stl implementierungen hab ich nochnicht benutzt, aber viel schneller als qstring wird man eine stringklasse wohl nicht implementieren können).

es geht mir ja garnicht um die sprache oder die bibliotheken. es geht mir um die runtime. gute string implementierungen oder eigene registry im binary des programms kann man auch ohne runtime haben. warum müssen also java und c# eine haben? was bringen die ausser das man statt 10 binarys nur ein jar file oder eine exe zum download anbieten muss. wo wir gerade dabei sind: funktioniert mono mit ner .net exe?

 

[[UPS]Erazor]

Vom Argument "Heutzutage haben alle xyz Ghz, CPU Cyklen sind billig" halte ich im allg. auch nix. Wenn du an deutschen Schulen gehst, wirste haufenweise rechner <500 Mhz finden die alle aktiv gebraucht werden.
Wenn man .Net wirklich verbreiten möchte, so muss es für die Schulen/Lehrer attraktiv werden. Mir ist bewusst, dass Lehrer bestenfalls 10% soviel wissen wie ein Schüler und davon bestenfalls die hälfte richtig ist, aber man kann schlecht auf nem 233er P2 mal ein .Net programm vorstellen... Java geht da noch, aber wird bei etwas komplexeren Programmen auch schon zur qual.
Da hilft es auch nicht, dass das Programm beim 2. oder 3. mal schnell läuft, dafür aber den Ram vollschreibt...

Glaubst du wirklich, dass sich Microsoft oder Sun um die "Entwickler" an deutschen Schulen scheren? .net und Java sind nix für kleine Spielchen sondern fürs Big Business wo Programmierer 1000€ am Tag kosten können. Die müssen auch entsprechend schnell und vor allem im Team programmieren können. Da interessieren doch keine Schüler/Lehrer, mit denen man nichtmal besonders viel Geld verdient.
FHs sind schon eher interessant, sind aber auch entsprechend ausgestattet.
Ich finds auch nicht besonders gut einfach leistungsfähigere Hardware unnötig zu beschäftigen aber wer in diesem schnelllebigen Geschäft mithalten will muss schnell entwickeln. Erfahrene Leute schaffen das mit C++ auch aber die ganzen Fachinformatiker (no offense) haben nicht genug Zeit um die Erfahrung zu sammeln bei diesen Anforderungen.

>C/C++ <-- Teilweise doch schon betagt (einfaches Bsp. Strings), schnell, für Zeitkritische anwendungen tauglich

Husky hat schon auf std::string hingewiesen, ist fast schon flexibler als java.lang.String und deutlich schneller sowieso. Bei reinem C ist das schon ein Hickhack aber mit C werden überwiegen nur noch die richtig systemnahen Sachen gemacht, wo es auf jeden einzelnen Takt ankommt.
Du solltest C und C++ nicht über einen Kamm scheren. C ist besser lesbares Assembler.
C++ ist vollständig objektorientert, lässt sich aber auch als C missbrauchen.

>Java <-- modern, sehr leicht portierbar, langsam, defizite in der GUI, (GC)

Was meinst du mit leicht portierbar? Die VM/JRE? Die ist nicht sooo leicht portierbar.
Langsam auch nicht unbedingt. Ok, langsamer als nativer Bytecode (ob C, Assembler oder was auch immer) aber dennoch ist das Framwork effizient designt.
Vor allem spricht für Java die Typsicherheit (ob man die toll findet steht auf einem anderen Blatt), die Plattformunabhängigkeit (die mit dem 1.5er Release nochmal deutlich besser wurde) und die Ausführbarkeit im Browser als Applet. Natürlich hats noch ein paar andere Tugenden und Nachteile, soll aber auch nur kurz angerissen sein.
Bei der GUI hat die 1.5er jetzt stark nachgelegt (u.a. OpenGL Beschleunigung von 2D Grafik).
Und wie bereits erwähnt gibt es SWT von IBM, welches auf die System Widgets zugreift und damit nochmal um Längen schneller ist als Swing.
Wenn man sich ein wenig mit Java GUI Programmierung auskennt, kann man hochperformante Grafik erzeugen. Nicht umsonst gibt es ein Java Media Framework für Mediaplayer und MP3 De/Encoding...

>C# <-- modern, effizienteres verhalten (Von MS für MS), nicht wirklich portierbar

Im Endeffekt für mich immer noch das gleiche wie Java nur von MS für MS wie du richtig schreibst.

Was bleibt ist die erkenntnis, dass man immer das nehmen sollte, was das problem schnell (programmiertechnisch) und effizient für eine bestimmte zielgruppe löst. Alles kann man leider nicht haben...

Wenn du mit effizient lösen den Aufwand des Programmierers meinst, bist du mit Java und .net bei komplexeren Sachen sicherlich besser dran. Einfache Sachen würde ich einfach weils schneller ist in C++ umsetzen. Natürlich auch solche wo es auf das letzte Bisschen Performance ankommt.
Einsatzbereiche wo std::vector schon als zu langsam gilt.

Ansonsten noch einen guten Rutsch ins neue Jahr...

@Siberian Husky: .net exe mit mono... Ich denk schon, ansonsten wäre das Klassenziel verfehlt Zumindest wenn du kein GUI drinhast, da hat mono einen Mix aus GTK+ und eigenen Klassen zusammengebaut soweit ich mich erinnere.

edit in blau

 

[CapFuture]

Das ich C und C++ nicht auf einen Kamm scheren darf ist mir klar, C oder besser C89 ist eine Teilmenge von C++.
Mit den Bibliotheken wie z.B. QT habe ich leider keine Erfahrung. Die meisten Programmierer werden erst die mitgelieferten Bibliotheken benutzen und dann sehn, dass es mit anderen schneller geht.
VM zu portieren ist nicht soo einfach, das stimmt, aber dies ist ja auch nicht die Aufgabe des Programmierers sondern die von z.B. Sun. Einfach portierbar heißt nach definition das man ein programm in der Programmiersprache P1 schnell von der Plattform A auf die Plattform B portieren kann ohne größere Änderungen am Programm durchzuführen. Von daher kann man sagen das Java programme leicht portierbar sind.

 

[Siberian..Husky]

naja das mit der portierbarkeit stimmt so nicht. den das hat mit der sprache wenig zutun solange es überall einen compiler/eine vm dafür gibt. es kommt auf die bibliothek an die man benutzt, den die sprache sollte von ganz alein vollkommen plattformunabhängig sein. zu c++ gehört nur die stl, und die läuft je nach implementierung auf so ziemlich jedem c++ compiler. der rest gehört nicht dazu, den muss man sich also selbst suchen. wer also plattformunabhängig in c++ programmieren will darf eben nicht das erst beste nehmen das sein betriebsystem zum compiler gepackt hat sondern der muss sich eben mal informieren.

das ist zwar sicher auch ein nachteil, der vorteil dabei ist aber das man bei c++ die wahl hat - bei java und vorallem bei c# ist man ja schon auf sun bzw. microsoft angewiesen.

mit einer plattformunabhängigen bibliothek kann man mit c++ genauso plattformunabhängig programmieren wie in java.

 

[[UPS]Erazor]

Du bist bei der Runtime nicht unbedingt auf Sun angewiesen. IBM bastelt ja auch seine eigenen Java VMs, die Spezifikation ist freigegeben. Natürlich wirst du als einzelner Entwickler wahrscheinlich keine konkurrenzfähige VM schreiben können, theorietisch möglich wäre es aber.
Bei .net scheint ja auch einiges über die Interna bekannt zu sein. Ansonsten wäre mono wohl schlecht möglich gewesen.

Bei Java über portierbar zu reden is irgendwie müßig. Java Programme sind also schon portiert wenn man wirklich von Portierung sprechen will. Solange du keinen native code verwendest brauchst du garnichts zu tun damit es auf einem anderen Rechner läuft.
Native Code (C/C++ Code (dll / SO / wie das auch immer heißen mag) der von Java verwendet/aufgerufen werden) muss natürlich mit dem gleichen Aufwand wie beliebiger C++ Code portiert werden. Native Code in Java dürfte equivalent zum "Unmanaged code" von C# sein, oder irre ich?

Noch was zu der Java GUI: Sie mag zwar langsamer sein, ist aber auf allen Systemen gleich anzusprechen. Das hat .net noch nicht geschafft.
Inwiefern QT oder GTK+ sich in die Windows Landschaft integrieren kann ich nicht beurteilen. Brauchts besondere Behandlung oder wird das komplett abstrahiert?

 

[Siberian..Husky]

ich meine auch nicht das man auf die runtime angewiesen ist, sondern auf die bilbiotheken. bei java und .net gibt es da keine auswahl. entweder man nimmt was microsoft und sun vorgesehen haben oder man sieht relativ alt aus. bei java gibt es uwar in ein paar bereichen erweiterungen, aber irgendwo baut alles auf den bilbiotheken von sun auf, soweit ich weiß zumindest.

den letzten absatz hab ich nicht so ganz verstanden, aber ich versuche es trotzdme einfach mal: Qt versucht sich unter jedem betriebsystem zu integrieren. unter windows und mac werden standardmässig also die betirebsystem eigenen öffnen dialoge benutzt, und unix/linux dementsprechend eigene, da es dort ja keinen standard gibt(bzw. Qt/kde mitlerweiel selbst einer ist). wenn man will kann man Qt programme also durchaus so schreiben das ein einfaches neu compileieren für die zielplatform reicht damit alles funktioniert. wem die windows dialoge nicht gefallen kann stattdesen aber auch die Qt dialoge unter windows nutzen, das windows klassik design (also die buttons von win95/98) unter linux oder motif unter windows nutzen. Qt sollte da also genausowenig eingeschränkt sein wie java, wenn es nicht sogar besser ist .

wie das bei GTK+ ist weiß ich allerdings nicht. eigentlich ist es ja nur eine Gui bibliothek. da fehtl also ganz sicher einiges an integration in das entsprechende system. zumindest was sachen wie die registry oder anderen kram angeht der nicht zur oberfläche gehört.

P.S.: wenn man will kann man auch ganz eigene skins für Qt schreiben wie es bei KDE ja üblich ist. die KDE Themes bauen ja auf QStyle von Qt auf.

 

[[UPS]Erazor]

ich meine auch nicht das man auf die runtime angewiesen ist, sondern auf die bilbiotheken. bei java und .net gibt es da keine auswahl. entweder man nimmt was microsoft und sun vorgesehen haben oder man sieht relativ alt aus. bei java gibt es uwar in ein paar bereichen erweiterungen, aber irgendwo baut alles auf den bilbiotheken von sun auf, soweit ich weiß zumindest.

Ich versteh die Bedenken nicht.
1. Die Bibliotheken sind so performant und erweiterbar wie möglich/nötig implementiert
2. Du kannst das meiste erweitern wenn du weißt was du tust (Vererbung kann nach hinten los gehen, überall)
3. Du kannst auch eine neue Bibliothek entwickeln und mitveröffentlichen (macht man mit DLLs und libs ja auch nicht anders)

den letzten absatz hab ich nicht so ganz verstanden, aber ich versuche es trotzdme einfach mal: Qt versucht sich unter jedem betriebsystem zu integrieren. unter windows und mac werden standardmässig also die betirebsystem eigenen öffnen dialoge benutzt, und unix/linux dementsprechend eigene, da es dort ja keinen standard gibt(bzw. Qt/kde mitlerweiel selbst einer ist). wenn man will kann man Qt programme also durchaus so schreiben das ein einfaches neu compileieren für die zielplatform reicht damit alles funktioniert. wem die windows dialoge nicht gefallen kann stattdesen aber auch die Qt dialoge unter windows nutzen, das windows klassik design (also die buttons von win95/98) unter linux oder motif unter windows nutzen. Qt sollte da also genausowenig eingeschränkt sein wie java, wenn es nicht sogar besser ist .

Anscheinend hast du doch verstanden Genau das meinte ich.
Danke für die Ausführungen.

wie das bei GTK+ ist weiß ich allerdings nicht. eigentlich ist es ja nur eine Gui bibliothek. da fehtl also ganz sicher einiges an integration in das entsprechende system. zumindest was sachen wie die registry oder anderen kram angeht der nicht zur oberfläche gehört.

Mit QT kann man also plattformunabhängig auf ne Registry zugreifen und bei Windows ist es dann die Windows Registry oder hab ich da was falsch verstanden?

P.S.: wenn man will kann man auch ganz eigene skins für Qt schreiben wie es bei KDE ja üblich ist. die KDE Themes bauen ja auf QStyle von Qt auf.

Die QStyles können aber nicht die Windows Themes direkt verwenden, oder? Ich glaub die sind bei Windows schneller implementiert weil se im Kernelmodus laufen (eigentlich pfui aber es läuft schneller).

Hmm... wurde teils OT, sorry

 

[Siberian..Husky]

Zum speichern von einstellungen gibts bei Qt die QSettings klasse. diese nutzt unter windows die registry, unter mac die carbon preferences api(wo auch immer die den kram dann speichert ) und unter allen anderen betriebsystemen textdateien.

es gibt einen QStyle unter windows der die windows XP themes nutzt. verwendet wird dabei allerdings eine eigene redering engine wie bei allen QStyles. ich glaube allerdings nicht das diese groß langsamer ist als windows selbst. zumindest habe ich noch kein Qt programm gesehen das eine träge ui hatte. der vorteil dabei ist das alle widgets echte klasse sind und man somit durch vererbung 100% des verhaltens ändern kann, was über die windows-api nicht möglich ist. SWT und .net machen das soweit ich weiß genauso.

 

[CFI]

...durch vererbung 100% des verhaltens ändern kann, was über die windows-api nicht möglich ist. SWT und .net machen das soweit ich weiß genauso.

Ja, in .net kann man z.B. mit override jede Funktion der Basisklasse ersetzen bzw. verändern ohne die Basisklasse anzurühren...

 

[Siberian..Husky]

na ich hoffe mal das da die basisklasse noch ein wort mitreden darf was da überschrieben wird und was nicht. sonst weicht das die datenkapselung bei oop ja gewaltig auf.

um zurück zum thema zu kommen: wie sieht das eigentlich mit asp .net aus? da kann man ja mitlerweile ähnlich wie bei java serverpages in c# entwickeln, oder hab ich das falsch verstanden? gibt es dafür den schon unterstützung bei mono? oder ist man für asp immernoch auf den iss angewiesen?