Hendriks Weblog

… Nachruf auf GG Artikel 5.

Ohne viele Worte. Für spezielle Anwendungen ist Mono SIMD (wohlgemerkt Mono, nicht Microsoft .NET ) schneller als C++: http://www.betanews.com/article/Mono_22_may_overtake_NET_in_some_critical_categories/1232551276

(Gut, wahrscheinlich haben die Leute hier bei der C++ Implementierung mal wieder kräftig geschlampt. Aber alleine die Tatsache, datenparallele Aufgaben in Mono genauso schnell ausführen zu können wie in C++, reicht ja schon aus.)

So eine Beschleunigung um Faktor 8-10 gegenüber normalen .NET-Anwendungen für den numerischen Bereich macht ein Interfacing zu C++/C natürlich auch reichlich überflüssig. Schade, dabei mag ich Template Meta Programming so sehr - das ist so schön geekig-esoterisch…

Eigentlich hatte ich ja gedacht, mein letzter Eintrag hätte alle deutlichen Schwachpunkte von C# angesprochen. Aber wie sich nach einer Diskussion gezeigt hat, habe ich doch glatt zwei wichtige Dinge übersehen:

• C# unterstützt keine checked exceptions. Die mögen vielen Leuten, gerade denen, die von der C++ Seite zu C#/Java kommen, vielleicht eh unnötig restriktiv erscheinen. Die Compilezeit-Sicherheiten, die man durch diesen Mechanismus gewinnt, sind jedoch enorm und können eine ganze Menge Fehler im frühzeitig verhindern. C# unterstützt so etwas leider nicht von Haus aus, sondern geht in Punkto Exception-Handling eher wieder in Richtung C++. Was einerseits sehr schade, aber andererseits jetzt wohl auch nicht mehr zu ändern ist.
• C# unterstützt keine Konstanten in Interfaces. Ich weiß ehrlich gesagt nicht, woran das liegt und was das soll - die IL unterstützt das offenbar sehr wohl. Selbiges gilt für Enumerationen. An vielen Stellen wäre so etwas doch extrem nützlich, gerade wenn es darum geht, Komponenteninterfaces nach außen zu tragen. So muss das alles dann in zusätzliche Hilfsklassen aufsplitten, globale Enums anlegen oder statt Interfaces abstrakte Klassen benutzen - was in vielen Fällen dank verbotenener Mehrfachvererbung nicht geht.

An dieser Stelle noch einmal herzlichen Dank an Jochen dafür, dass er mich auf diese Punkte aufmerksam gemacht hat.

Der große Hype ist vorbei. Ich kann auf 2 Jahre professionelle Softwareentwicklung mit .NET unter C# zurück blicken und ein Resüme ziehen. Entgegen dem, was vielerorts behauptet wird, und was ich zu Beginn und für lange Zeit auch gerne geglaubt habe, ist C# eben kein besseres Java. Im Gegenteil, es löst viele Dinge nur vermeintlich elegant, und offenbart nicht selten einige eklatante Designschnitzer, die im normalen Tagesbetrieb nicht auffallen:

• Properties: Properties sind ein nettes Sprachschmankerl. Wirklich Zeit sparen sie aber nicht, denn das Implementieren dauert genau so lange wie bei normalen getter/setter Methoden. Zudem erkennt man im Produktionscode keine Fehler mehr, die das Data-Hiding-Prinzip verletzen, weil sich der Zugriff auf Datenattribute und der Zugriff über Properties optisch nicht voneinander unterscheiden. Das an sich wäre kein Problem, wenn man Datenmember nur als protected oder private deklarieren könnte - so allerdings ist das Ganze recht missverständlich.
• Structs: Eigentlich ist die Verwendung von benutzerdefinierten Werttypen eine schöne Sache, aber auch hier wurde meiner Meinung nach das Konzept nicht bis zum Ende durchgedacht. Ich lege Structs in C# mit new an - wie einen Referenztypen! Habe dann aber einen Werttyp. Wie soll ich das Leuten mit wenig Programmiererfahrung klar machen? Wie vermeide ich Fehler, sobald noch weitere Sprachen mit ins Spiel kommen (lege ich structs in C++/CLI mit gcnew an, habe ich nämlich plötzlich Referenztypen, die anstandslos kompiliert werden. Der ganze Mist funktioniert dann aber nicht mehr - und das bedeutet dann wieder stundenlanges Debuggen, wenn jemand mal kurz nicht aufgepasst hat!).
• Attribute: Sind zugegebenermassen toll. Aber die habe ich Form von Annotations in Java seit Version 1.5 auch.
• Lambda-Funktionen: Warum unterminiere ich eine objektorientierte Sprache durch funktionale Elemente, die dort eigentlich nicht das geringste verloren haben? Die Syntax ist Anfängern nicht begreiflich zu machen und verwendet einen Operator, der an anderer Stelle eine völlig andere Bedeutung hat. Zudem brauche ich die Dinger hier garnicht - wenn ich funktional entwickeln will, dann nehme ich F# oder IronPython - damit geht das dann nämlich auch komfortabel. Dazu kommt noch, dass ich denselben Effekt sowieso schon mit anonymen Delegaten erreichen kann. Und - wozu kann ich denn die Sprachen im CLI nach belieben mischen, wenn ich doch wieder alle Konzepte in eine Sprache packe? Was kommt als nächstes - prozedurale Erweiterungen für C#?
• Der neueste Gag: Dynamische Typisierung in C# 4.0. Jetzt wird also auch noch die statische Typisierung von C# ausgehebelt - die in kompilierbaren Sprachen durchaus ihre Berechtigung hat, da sie schließlich eine Vielzahl von Flüchtigkeitsfehlern verhindert.
• Konvertierungsoperatoren: In C# kann ich diese Operatoren überladen. Das implizite Konvertierungen böse (weil extrem fehleranfällig) sind, wissen wir aber schon seit langem aus C++. Anlegen kann ich sie hier trotzdem. Explizite Konvertierungen könnte ich auch prima über normalen Methoden abhandeln. C# benutzt dafür dagegen ein eigenes Sprachkonstrukt - und das auch nicht durchgängig - oder warum hat jedes Objekt eine Methode ToString? Sinnvoll dagegen wären implizite Konvertierungen dagegen bei der Umwandlung von primitiven Typen in Strings - genau das unterstützt C# aber wieder nicht.
• In eine ähnliche Kategorie fällt das Überladen von arithmetischen Operatoren. Das ist in beinahe allen Fällen unnütz (einzige Ausnahme - Zahlentupel aller Art (z.B. komplexe Zahlen oder Vektoren) oder Tensoren höherer Ordnung (z.B. Matrizen)), kann aber, da man die Operatoren beliebig implementieren kann, natürlich sehr schnell nach hinten los gehen. Auch hier bezahlt man ein klein wenig Bequemlichkeit mit einem großen zusätzlichen Risiko.
• Grobe Designschnitzer in der Sprache. Bestes Beispiel: Arrays implementieren die Schnittstelle einer Liste. Das heißt ich kann Arrays implizit in Listen konvertieren und darf mich dann wundern, warum meine Listenoperationen zur Laufzeit Ausnahmen werfen. In Java dagegen ist für eine Konvertierung einen expliziter Aufruf von as_list() notwendig. Da weiß man schon eher, woran man ist.
• Erweiterungsmethoden: Dieses neue Feature von C# 3.0 erlaubt es uns, nachträglich zu Typen, die eigentlich als sealed deklariert worden sind, neue Methoden hinzu zu fügen. Das führt natürlich das gesamte Konzept der Kapselung ad absurdum.
• Delegaten und Events: …sind eigentlich nur abgekürzte Schreibweisen für Funktionsreferenzen oder Funktoren. Während Events damit quasi dem Listener-Mechanismus in Java entsprechen (und eigentlich auch so verwendet werden könnten - da bräuchte man kein separates Schlüsselwort für), sind erstere extrem gefährlich, dank ihres =-Operators. Damit kicke ich nämlich ganz schnell registrierte Delegaten wieder heraus und wundere mich dann, warum meine dynamischen Aufrufe nicht mehr funktionieren.

Letztendlich komme ich zu folgendem Fazit: C# ist durch die ständige (und meiner Meinung nach überflüssige) Integration neuer Features auf dem besten Wege, ein zweites C++ zu werden. Das Orthogonalitätsprinzip wird von den Sprachdesignern immer wieder erneut verletzt, was die Fehleranfälligkeit erhöht, den Einstieg in die Sprache erschwert und das finden von Lösungen unnötig kompliziert macht. Java verzichtet auf diesen ganzen Schnickschnack; und dies ist nur oberflächlich ein Nachteil. Die Entwicklungen komplexerer Sprachkonstrukte erfolgt in Java traditionell durch automatisierte Funktionen in den gängigen IDE’s (Eclipse, z.T. auch NetBeans), weshalb in der Sprache selbst auf Bequemlichkeitsfunktionen wie Properties und LINQ verzichtet werden kann. Traurigerweise bietet auch das Visual Studio mittlerweile viele dieser Funktionen an (Implement interface, Refactoring, Create getter/setter), so dass diese Erweiterungen eigentlich garnicht nötig wären.

Eigentlich finde ich diese Entwicklung sehr schade; in vielen Belangen scheint Microsoft endlich im 21. Jahrhundert anzukommen (Endlich ein Visual Studio mit UML-Unterstützung, nach 20 Jahren hat man auch bei MS endlich begriffen, was ein Model-View-Controller-Pattern ist; man entwirft ein Framework, dessen Architektur nichts taugt, komplett neu) zu sein. Warum man dann beim Design der neuen Vorzeigesprache so grundlegende Fehler macht, die jeder Informatikstudent in Theorie von Programmiersprachen vermeiden lernt, ist mir persönlich ein Rätsel.

Letztendlich muss ich natürlich beruflich damit leben, weiterhin mit C# zu entwickeln (besser als Desktopprodukte mit C++ zu entwickeln ist es allemal) - dabei werde ich mich aber wie bisher ans K.I.S.S.-Prinzip halten und im Team darauf setzen, dass wir nur Techniken einsetzen, die auch alle nachvollziehen können. Keine Lambafunktionen, kein LINQ, so lange keine Datenbanken im Spiel sind, sparsamer Einsatz von structs und kein nachträgliches Erweitern von sealed-Typen. Auf das der Debugger nicht zu heiß läuft und es bei einer einstelligen Zahl von Abstürzen des Visual Studios am typischen Arbeittag bleibt…

Eigentlich würde ich mir ja nicht die Mühe machen, hier ein neues Metal-Album vorzustellen. Das Debut Denied by Reign von Severed Fifth hat allerdings schon allein auf Grund der Umstände seines Erscheinens ein wenig Aufmerksamkeit verdient. Severed
Fifth ist ein Musikprojekt des Ubuntu Community Managers Jono Bacon,
der mit seiner Veröffentlichung, der eigenen Aussage nach, "neue Wege
im Vertrieb von Musik" erforschen und beschreiten möchte.

Denied by Reign erscheint unter einer sehr liberalen Creative Commons Lizenz, ist frei verfügbar und darf nach eigenem Gutdünken weiter gegeben werden. Auch das Remixen ist explizit erlaubt. In diesem Sinne nimmt das Album also durchaus einen momentan absolut einzigartigen Ausnahmestatus ein. Jono sieht dabei seine kommerziellen Interessen auch keineswegs als gefährdet an. In einem aktuellen Interview mit Ars Technica sagt er, dass ihm der Weg über Konzerte, CDs und Merchandising immer noch Geld mit seiner Musik zu verdienen, ja immer noch offen stehe, auch wenn dies nicht sein Hauptinteresse sei.

 Ach ja, das Wichtigste zuletzt, anhörbar ist das Ganze auch - zumindest, wenn man Metal mag.

Danke Wired, dank euch weiß ich jetzt endlich, woran mich das Verhalten der Musikindustrie gegenüber ihrer Kundschaft schon die ganze Zeit erinnert:

Tatsächlich sieht es so aus, als bekämen die Amerikaner jetzt die erste Quittung für das, was sie vor 10 Jahren verbrochen haben. Zahavah Levine antwortet betont schnippisch auf die Anfrage der McCain-schen Wahlmaschinerie, doch nicht immer gleich alle Wahlkampfvidoeos zu löschen, sobald eine Takedown Notice bei YouTube eintrudelt.

Ich hoffe ja inständig, dass man auch hierzulande etwas daraus lernt. Obwohl das jüngste Urteil gegen Google mich eher eine gewisse Ignoranz gegenüber diesen Dingen vermuten lässt. Irgendwie ist es schon traurig, dass so viele Entscheidungsträger auch jetzt, nach fast 10 Jahren, immer noch nicht im neuen Jahrtausend angekommen sind. 

Wahrscheinlich müssen die Lobbyisten beziehungsweise ihre dankbaren Freunde aus der Industrie erst noch viel massiver durch ihre eigenen Gesetze, sei es der DMCA in den USA oder die Urheberrechtsnovelle in Deutschland, behindert werden, damit man einsieht, welche massiven und kulturfeindlichen Fehler man gemacht hat.

Wie auch schon die Vorgänger liefert Windows Vista einige nette, kleine Programme mit, die einem die tägliche Arbeit deutlich erleichtern können. Besonders erwähnenswert finde ich dabei Stikynot, Journal und Snippingtool, die eigentlich dem Tablet PC vorbehalten sind, aber auch im normalen Betrieb sicherlich einmal nützlich sein sollen. Auf der Kommandozeile gibt es zudem mklink, ein Befehl, mit dem symbolische Verweise auf Dateien oder Verzeichnisse angelegt werden können (Unix-Benutzer kennen das und arbeiten regelmäßig damit). Mehr zum Thema findet sich bei der PCWelt.

Es ist mal wieder an der Zeit, für eine kleine, aber feine Veranstaltung ein wenig Werbung zu machen. Vom 5. - 7. September 2008 findet im Fritz-Henßler-Haus in Dortmund-Mitte die Earthdawn/Fading Suns-Convention 2008 statt. Neben zahlreichen Fans werden die Line Developer der beiden Spiele (Carsten Damm und Alex Wichertt) sowie die Zeichnerin/Designerin Kathy Schad (alles meines Eindrucks nach wirklich sehr nette Leute übrigens) anwesend. Es wird ein kleines Programm geben, und natürlich jede Menge Spielrunden (unter anderem auch von mir, etwas Eigenwerbung muss ja auch sein… ). Mehr Informationen gibt es natürlich auf der offiziellen Seite des Cons. Ich hoffe, wir sehen uns dort…

Mehr oder weniger durch Zufall (okay, Zufall war’s ja nicht unbedingt, eigentlich war es eher der Verdienst dieser Jungs hier, bei deren Werk ich wirklich aus dem Lachen nicht mehr ‘raus gekommen bin) stieß ich auf diese höchst bemerkenswerte Sere von Videopodcasts. Drawn by pain erzählt die Geschichte von Emily, die ihre Ängste, ihre Furcht und ihre Wut in sich hinein frisst und durch ihre Comiczeichnungen versucht zu verarbeiten. Doch irgendwann wird mehr daraus, und ihr Talent wird zu ihrem Werkzeug der Rache - im blutigsten Sinne. Die Serie ist äußerst professionell in Szene gesetzt, Bilder wie Musik wirken ebenso durchdacht und tiefsinnig wie auch verstörend. Beinahe jede Folge für sich ist schon ein Kunstwerk, ein Mahnmal für die dunklen Abgründe des menschlichen Verhaltens. Deshalb: Keinesfalls verpassen! Zum Einstieg hier schon mal der Trailer: