| |
 |
| Neue Features für C# (update) |
|
|
Veröffentlicht durch tbf am Freitag 08. November, 23:56
Aus der immer-hinten-anbauen Abteilung
|
|
|
|
|
Auf der Mono-Liste wird gerade ein ZDNet-Artikel diskutiert, laut dem Microsoft plant in der kommende Version des Visual Studio C# um einige leckere Features wie Templates und anonyme Funktionen anzureichern.
|
|
|
|
|
|
|
Bei C# scheint man das Erfolgsrezept der Sprache fortzusetzen und weiteren syntaktischen Zucker einzubauen. So wird man "Generics" - eine Variante der aus ADA und C++ bekannten Templates unterstützen (btw: "Hallo Sun, wo bleibt Java 1.5?"). Ausserdem sollen, wie es sich für jede sinnvolle Programmiersprache gehört, anonyme Funktionen (aka. "lambda" oder "sub") eingebaut werden. Bei all dieser oberflächlichen Politur scheint man sich nicht auf den letzten (und meinem Eindruck nach realistischen) Benchmarkergebnissen auszuruhen und feilt weiter an der excellenten Ausführungsgeschwindigkeit: So sind die Templates nicht nur per Parserhack implementiert, sondern beruhen - wie aus informierten Kreisen verlautet - auf Erweiterungen des CIL-Befehlssatzes. Ob die erwähnte Unterstützung von "Iteratoren" auf ähnlichem Niveau arbeitet, war nicht in Erfahrung zu bringen. Eine derartige Interpretation ist aber naheliegend, da die .NET-Umgebung bereits ein IEnumerable-Interface vorsieht und dieses intensiv - teilweise sogar durch Sprachkonstrukte wie "foreach" unterstützt - verwendet wird. Absolut unklar bleibt, was der Artikel mit den sogenannten "partial types" beschreiben will.
Bei einigen dürfte jetzt sicher eine grosse 23 aufblinken: "Erst anfüttern und dann properitär erweitern". Dieser Befürchtung ist aber entgegenzusetzen, dass wohlinformierte Kreise, die beschriebenden Änderungen allesamt auf dem Weg ECMA wissen.
Update: Auf dem Mono IRC-Channel wurde gerade ein Link zu einem fundierterem Artikel auf Got Dot Net gepostet. Dieser Seite gibt's die Orginal Powerpoint-Präsi, Beispielcode und eine FAQ.
|
|
|
|
< MySQL AB und Nusphere rauchen Friedenspfeife | Druckausgabe | ADSL über Freileitungen: Swisscom testet > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
|
Nun nimmt es mich aber wunder, dass hier noch immer kein Kommentar abgegeben wurde, dabei enthält dieser Artikel doch so ziemlich alle Reizwörter, die momentan "in" sind...
Nee - Spass beiseite. Aber ich hätte schon gedacht, dass sich für C# (zumal es Mono gibt, und wir somit zumindest eine Alternative zu .NET haben) mehr von euch interessieren würden. Aber anscheinend wird C# von einem Großteil der der Community absichtlich ignoriert, weil es "von M$ kommt". Hey Leute - C# könnte der legitime Nachfolger von Java werden, weil es endlich die Anforderungen erfüllt, die Java nie erfüllen konnte!
Und noch was: Nur weil C# von M$ kommt, dürfen wir es nicht riskieren, irgendwann zu den Dinos zu gehören. Dann hätte die Studie nämlich doch recht, wenn es da heisst: "Unix will become a back-end, legacy OS platform by 2003/2004", und das will doch keiner von uns, oder? Also zeigt wenigsten euer (wenn auch nur repräsentatives) Interesse an C# und Mono, und macht ein paar comments =)
--
Herr Spion - Telefon!
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 10. November, 11:16 MEW (#6)
|
|
|
|
|
C# könnte der legitime Nachfolger von Java werden, weil es endlich die Anforderungen erfüllt, die Java nie erfüllen konnte
Welche denn? Etwa Plattformunabhängigkeit?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Na dann blicken wir den Fakten mal ins Auge: Plattformunabhängigkeit ist vor allem eine Forderung aus dem Desktopbereich, denn dieser galt Anfang der Neunziger, bevor Microsoft alle übertölpet hat, als wahnsinnig lukrativ (wer errinnert sich heute noch an OS/2, OpenStep, OpenWindows, IRIX, GEOS, ...), war in der Folge dann auch ebenso heterogen. Die Java-Plattform wurde daraufhin auch vor allem entwickelt, um dem Mangel an Desktop-Applikationen für Solaris abhilfe zu verschaffen. Belege: Werbemittel von 1995, die ersten Beispielapplikationen für Java, die Gewichtung der Klassen in Java 1.0 usw.
Wie wir aber alle wissen, ist Java auf dem Desktop grandios gescheitert. Zum Glück für Java war man schnell in der Lage, Java auf den durchs Internet boomenden Servermarkt anzupassen: In den Boomjahren zählte vor allem Rapid-Development, was Java mit Sicherheit leistet. Desweitern muss man schon arg risikofreudig sein, Resourcen auf einem Internetserver manuell zu verwalten (so wie es C/C++ fordert, setzt man keinen Garbage-Collector ein). Plattformunabhängigkeit hingegen ist für Serverapplikationen nun wirklich kein Killerargument: Wer seriös plant wird kaum sehr häufig die Serverplattform wechseln, ein homogenes Serverumfeld aufbauen. Zudem ist man auf Serverseite - solange Server != Mainframe - immer mit einer POSIX-kompatiblen Umgebung konfrontiert sein: Sprich sauber gehackte C, C++, Perl, Shell-Programme sind plattformunabhängig. Da auch Javaapps nur plattformunabhängig sind, wenn sie klar nach den extrem restriktiven Pure-Java Restriktionen gehackt sind (was kaum eine Javaapp erfüllt), frage ich: So what?
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
Heh. Der Test ist wirklich extrem rudimentär
In der Tat! Ich habe mir nicht die Zeit genommen, ein umfangreiches, mehr oder weniger repräsentatives Benchmark-Framework zu schreiben.
Hast Du die Ausgabe der Programme in eine Datei oder gar nach /dev/null umgeleitet?
Nein, direkt auf die Konsole geschrieben.
Sonst ist dies vorallem ein Test der Terminalemulationen von Linux und Windows XP
Das ist es nicht, dazu sind die gemessenen Unterschiede zwischen den einzelnen REs auf den jeweiligen Plattformen zu gross. Es handelt sich aber, wie im Disclaimer (siehe Conclusions) vermerkt, um einen sehr spezifischen Test. Also keinerlei Ansprüche auf Repräsentativität (vgl. auch Fussnote [2]). Es geht auch nicht um einen allgemeinen Vergleich zwischen Windows XP und Linux bezüglich der Leistungsfähigkeit der REs.
Einige Resultate (immer in Bezug auf diesen spezifischen Test!) finde ich trotz der beschränkten Aussagekraft noch interessant, z.B. dass Mono besser abschgeschnitten hat als die MS CLR. Ich habe einen "Home-Run" der MS CLR erwartet.
Oder auch die recht unterschiedliche Dateigrösse des CIL Codes, je nachdem, ob mit dem .NET Compiler oder mit dem Mono Compiler generiert. Die Ursache müsste man allerdings noch untersuchen (siehe letzter Punkt der Conclusions).
Bei meiner (informellen) Evaluation von VS.NET vor einiger Zeit hatte ich eigentlich auch einen guten Gesamteindruck von der Performance der MS CLR erhalten. Meine kleine C#-GUI-Applikation schien wesentlich schneller zu laufen als bei Java-Applikationen mit Swing üblich (qualitativer Eindruck, gemessen habe ich es nicht). Vermutlich ist das aber weniger ein Punkt zu Gunsten der MS CLR als zu Ungunsten von Swing. Java-GUI-Applikationen, die das native
Standard Widget Toolkit von IBM verwenden, habe ich subjektiv ebenfalls als einiges schneller empfunden als typische Swing-Applikationen.
Ich würde Benchmark-Resultate stets mit Vorsicht geniessen und von Verallgemeinerungen absehen, ausser sie seien vertretbar.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 10. November, 11:18 MEW (#7)
|
|
|
|
|
|
|
|
|
|
