In den vergangenen Jahren ist mein Konsum von Fachbüchern stetig gesunken. Schuld an dieser Entwicklung ist letztlich das Internet, das es mir ermöglicht, nahezu alle Informationen nicht nur schneller, sondern vor allem zielgerichtet, kostenlos und häufig auch in aktuellerer Form zu finden.

Speziell für Entwickler bieten so wohl Google wie auch die MSDN inzwischen so vielfältige und detaillierte Informationen, dass es nur noch selten sinnvoll ist, Fachbücher zu kaufen, deren Inhalt nach zwei oder spätestens drei Jahren nicht mehr dem technischen Stand der Dinge entspricht, und die in den wenigsten Fällen darauf ausgerichtet sind, nicht sequenziell gelesen zu werden.

Dennoch gibt es dem Internet und Trends wie den E-Books zum Trotz einige Perlen unter den Fachbüchern, die es meiner Meinung nach durchaus zu kaufen lohnt, alleine schon deshalb, weil man mit Büchern eben all das machen kann, was mit elektronischen Medien nicht geht: Das Spektrum an Argumenten reicht von der Ergänzung handschriftlicher Notizen bis hin zu der Möglichkeit, ein Buch auch im Bett oder im Park lesen zu können.

Eine dieser zeitlosen Perlen ist vor einigen Tagen in einer zweiten, speziell für C# 3.0 und .NET 3.5 aktualisierten Auflage erschienen: Framework Design Guidelines von Krzysztof Cwalina und Brad Abrams.

Dieses Buch widmet sich der Aufgabe, zu klären, welche Aspekte beim Entwurf eines Frameworks zu beachten sind, um ein konsistentes, durchdachtes und gleichzeitig erweiterbares Framework zu erhalten. Das ganze Buch ist dabei quasi als Liste von "Do"s und "Don't"s aufgebaut, so dass man gezielt zu jedem einzelnen Thema nachschlagen kann, wie man es machen sollte - und wie eben nicht.

Das Buch ist in Themenblöcken aufgebaut, die sich wie folgt gliedern:

• Auswahl geeigneter Namen
• Beziehungen zwischen Typen
• Interner Aufbau von Typen
• Vererbung und Erweiterbarkeit
• Entwurf und Behandlung von Fehlern
• Richtlinien für häufig verwendete Typen
• Richtlinien für häufig verwendete Muster
• Programmierrichtlinien für C#
• Einsatz von FxCop

Insgesamt ist dieses Buch ein ausgesprochen praktischer Begleiter für jeden Entwickler und Architekten, und lehrt viel über guten Stil und beantwortet ganz nebenbei einige der Fragen, warum gewisse Dinge in .NET so und nicht anders umgesetzt wurden. Kurzum: Uneingeschränkt empfehlenswert!

Nach meinem Review von LINQ in Action von Fabrice Marguerie, Steve Eichert und Jim Wooley habe ich mir das Buch Windows PowerShell in Action von Bruce Payette bestellt, dessen Lektüre ich nun abgeschlossen habe.

Meine Erwartungen an das Buch waren hoch gesteckt: Auf der einen Seite wollte ich eine detaillierte Einführung in die PowerShell und die ihr zu Grunde liegenden Konzepte, auf der anderen Seite allerdings auch einen Überblick über die verfügbaren Cmdlets, und zu guter letzt auch Tipps und Tricks zur Programmierung der PowerShell - quasi eine gelungene Mischung aus Einführung, Lehrbuch und Referenz.

Nachdem ich Windows PowerShell in Action nun durchgearbeitet habe, kann ich sagen, dass es als Lehrbuch und Referenz ausgesprochen gut geeignet ist, dass allerdings die Einführung deutlich zu kurz kommt. Zwar werden alle wichtigen Aspekte der PowerShell angesprochen, sämtliche Inhalte verbleiben aber auf einem verhältnismäßig theoretischen Niveau - die Praxis kommt für meinen Geschmack deutlich zu kurz.

Laut Rückentext zielt das Buch so wohl auf Administratoren wie auch Entwickler ab, und möchte diesen ein Tutorial an die Hand geben. Ein Tutorial ist aber, laut Wikipedia, eine

"schriftliche Gebrauchsanleitung, die mit Hilfe von [...] Beispielen Schritt für Schritt erklärt, wie man mit einem Computerprogramm umgeht oder bestimmte Ergebnisse erzielt."

Und genau diese Schritt-für-Schritt-Anleitung bietet Windows PowerShell in Action eben nicht. Wie gesagt, als Lehrbuch und Referenz ist das Buch unschlagbar, als Einführung ist es aber leider eher weniger geeignet.

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, zukünftig jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Heute, am 1. Dezember 2008, ist es nun endlich so weit, unser Thema für diesen Monat lautet:

Dynamic Language Runtime: .NET, quo vadis?

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir der Dynamic Language Runtime gegenüberstehen, ob wir ihre Existenz positiv oder negativ bewerten, und welche Möglichkeiten und Risiken sie birgt. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Im Rahmen von Silverlight 2.0 hat Microsoft die Anzahl verfügbarer Sprachen für .NET erhöht: Mit IronPython und IronRuby stehen nun erstmals auch Vertreter der dynamischen Sprachen für die Entwicklung unter .NET zur Verfügung. Als Fundament dient in diesem Fall die Dynamic Language Runtime (DLR), die auf Basis der CLR die Grundlage zur Ausführung dynamischer Sprache ermöglicht.

Die Verfügbarkeit der DLR wirft einige Fragen auf, deren Relevanz nochmals durch einige der Veränderungen hervorgehoben wird, die Einzug in Visual Basic 9 gehalten haben, allen voran der native Datentyp zur Verarbeitung von XML. Offensichtlich strebt Microsoft eine deutlich breitere Unterstützung von dynamischen Sprachen und dynamischen Sprachelementen an, als in der Regel angenommen.

Die Frage ist, welche Konsequenzen sich daraus für die eigene Arbeit und .NET im Allgemeinen ergeben.

Grundsätzlich kann gesagt werden, dass sich Sprachen in der Regel eindeutig der Klasse der dynamischen oder der statischen Sprachen zuordnen lassen. Zwar gibt es einige Ausnahmen wie beispielsweise Visual Basic 9, das eher eine Art Hybrid darstellt, doch Ausnahmen bestätigen bekanntlich die Regel.

Das wesentliche Merkmal einer dynamischen gegenüber einer statischen Sprache ist, dass der Typ einer Variablen erst zur Lauf- und nicht bereits zur Übersetzungszeit bekannt ist, und sich gegebenenfalls auch im Nachhinein noch ändern kann. Der Vorteil liegt auf der Hand: Die aufwändige händische Typisierung entfällt, zudem bieten dynamische Typen durchaus Vorteile, was die Flexibilität des auszuführenden Codes betrifft.

Allerdings findet sich dort, wo Licht ist, auch Schatten: Diese Vorteile erkauft man sich als Entwickler nämlich zum einen mit einer geringfügig langsameren Ausführung, da zahlreiche Prüfungen auf den zur Laufzeit ausgeführt werden müssen, zum anderen mit einer erschwerten Fehlersuche, da Typisierungsfehler ebenfalls erst zur Laufzeit und nicht bereits zur Übersetzungszeit auftreten.

Die Frage lautet also, welchen Tod man sterben will. In den vergangenen Jahren war die Tendenz klar auszumachen: Während Skriptsprachen, die üblicherweise eine dynamische Typisierung bevorzugen, im Bereich der Administration und der Webentwicklung zu finden waren, hat sich die professionelle Softwareentwicklung (auf dem Desktop) mehr und mehr zu Sprachen mit statischer Typisierung zugewandt. Zu gewichtig waren hier die Vorteile, die sich aus der vom Compiler garantierten Fehlerfreiheit bezüglich Typisierung ergeben haben.

Nun wachsen diese beiden Welten der Web- und der professionellen Softwareentwicklung (auf dem Desktop) mit der in Silverlight enthaltenen DLR zusammen. Auch wenn diese noch nicht für das große .NET Framework zur Verfügung steht, ist dies nur noch eine Frage der Zeit, und die Frage lautet für uns Entwickler letztlich: Lohnt sich die Beschäftigung mit der DLR, mit den entsprechenden dynamischen Sprachen wie IronPython und IronRuby, oder wird man auch zukünftig mit einer rein statischen Sprache auf der sicheren Seite sein?

Ebenso bedeutet dies für die Webentwicklung, dass statische Sprachen durch die Verfügbarkeit von .NET mehr und mehr Einzug halten werden, zumal immer mehr Firmen ihre Produkte vom Desktop in das Web verlagern. Die Möglichkeit, ASP.NET-Anwendungen auf Basis von C# zu schreiben, war hierbei nur der Anfang, mit Silverlight bekommt C# im Web nun nochmals einen ganz anderen Stellenwert.

Um die Frage, auf welches Pferd man nun zukünftig setzen sollte, beantworten zu können, muss man meiner Meinung nach zunächst klären, warum Microsoft Projekte wie die Dynamic Language Runtime ins Leben ruft. Sicherlich ist ein Grund hierfür, dass gewisse Aufgaben mit dynamischen Sprachen schlichtweg schneller, kompakter und eleganter zu lösen sind.

Ausschlaggebend ist meines Erachtens aber ein ganz anderer Grund, dessen Wurzeln schon einige Jahre zurückreichen: Als Microsoft im Jahre 2002 das .NET Framework und damit einhergehend die Sprachen C# und Visual Basic .NET vorstellte, war die Empörung unter Entwicklern, die bislang mit Visual Basic Classic gearbeitet haben, groß, denn außer dem Namen hatte Visual Basic .NET mit dem ursprünglichen Visual Basic nicht mehr viel gemeinsam.

Microsoft hat damals versucht, den Visual Basic-Entwicklern den "akademischen" objektorientierten Ansatz von .NET unterzuschieben. Der Effekt war, dass die wenigsten Entwickler den Sprung auf Visual Basic .NET gewagt haben, sondern statt dessen auf andere Lösungen umgestiegen sind, die näher an ihrer Welt waren, allen voran sicherlich auf Delphi.

Mit Visual Basic 9 versucht Microsoft nun, diesen Fehler wieder auszubügeln, indem Visual Basic 9 sich durch die Integration dynamischer Sprachelemente wieder stärker an die Sprache annähert, die Visual Basic Classic einmal war. Visual Basic 9 ist sozusagen der Versuch, .NET auch bei nicht professionellen und weniger akademisch denkenden Entwicklern als Plattform zu etablieren. Da der Desktop aber zunehmend an Bedeutung verliert, muss Microsoft auch im Web eine entsprechende Lösung anbieten.

Genau diese Lücke wird durch die Dynamic Language Runtime gefüllt. Die Webentwickler, die bislang nicht auf ASP.NET umgestiegen sind, haben in der Vergangenheit nicht mit Visual Basic Classic gearbeitet, sondern mit Sprachen wie PHP, Ruby, Python oder Perl. All diesen Sprachen ist gemein, dass es sich um dynamische Sprachen handelt. Zu glauben, dass die Entwickler, die bei der Einführung von ASP.NET nicht auf C# umgestiegen sind, jetzt im Rahmen von Silverlight auf C# umsteigen würden, wäre naiv.

Deshalb lautet die einzig logische Konsequenz für Microsoft, die Entwicklung von Silverlight auf Basis von dynamischen Sprachen zu ermöglichen. Dies geschieht aber wohgemerkt nur zusätzlich, denn es wäre ebenso naiv zu glauben, Microsoft würde die Unterstützung von C# als Lingua Franca für .NET drosseln oder gar einstellen.

Daher kann das Fazit zur Dynamic Language Runtime nur lauten: Wer bislang mit C# oder einer anderen statischen Sprache zufrieden war, kann ohne Bedenken bei dieser Sprache bleiben. Wer sich aber immer schon gewünscht hätte, unter .NET auf Basis einer dynamischen Sprache zu entwickeln, der bekommt nun die Gelegenheit dazu - und zwar als .NET-Bürger erster Klasse.

Ich für meinen Teil glaube, dass diese Koexistenz der beiden Welten .NET insgesamt voranbringen wird, da es besser möglich wird, das am besten geeignete Werkzeug für die jeweilige Aufgabe zu wählen, ohne eine ausgereifte Plattform wie .NET verlassen zu müssen.