Wirbel um Visual Studio 2010 und .NET 4: über Nice-to-have- und Fundamentalfeatures

Inhaltsverzeichnis

Anders als noch zu Zeiten von Visual Basic vereint ein neues Release von Visual Studio und .NET heute Unmengen von Neuerungen, die in ihrer Gänze kaum mehr nachzuvollziehen sind. Neben zahlreichen Aufhübschungen findet unser Autor Ralf Westphal vor allem Gefallen an der Integration von F#.

Silvester 1997 war es, wenn ich mich recht erinnere, da ich mich vor einem gemütlichen Abend mit meiner Frau zu einem Hotel in Hamburg stahl. Es war dunkel und nasskalt, aber mich erwartete in seinem Zimmer ein damals bekannter "community influencer" der Visual-Basic-Gemeinde. Dieser Mister X gab mir unter verschwörerischem Blick eine CD mit einer geheimen Vorabversion von VB6. Wenn auch inoffiziell gehörte ich damit zu einem erlauchten Kreis: den Beta-Testern meiner geliebten Entwicklungsplattform. Das gab mir einen Vorsprung beim Lernen und bei der Berichterstattung in der Basicpro. Mein Glück war perfekt.

"Es geht voran"

Frühjahr 2010 ist es nun. Von Geheimnissen keine Spur mehr. Die Entwicklung unserer geliebten Entwicklungsplattform .NET findet schon lange nicht mehr im Geheimen statt. Man möchte fast meinen, Microsoft habe in den letzten Jahren eine Persönlichkeitsstörung entwickelt und sei zum Exhibitionisten geworden. Seine besten Teile zeigt die Firma jedem, auch wenn er sie nicht sehen will. Man kommt kaum am kleinsten Zucken von Microsofts Entwicklungs- und Forschungsabteilung vorbei. Lang erwartete Releases, die endlich vielfach beklagte Defizite beheben oder wahre Sprünge der Softwareentwicklung verheißen, gibt es nicht mehr. Veröffentlichungen wie Visual Studio 2010 und .NET 4 sind nur noch eine Formsache. Von Überraschung kann am Release-Tag keine Rede mehr sein. Wie im Fußball gilt eher: Nach dem Release ist vor dem Release. Die Entwicklungsplattform befindet sich in ständig sichtbarer Bewegung. "Keine Atempause. Geschichte wird gemacht", sang Peter Hein von Fehlfarben vor rund 30 Jahren und nahm damit den heutigen öffentlichen Microsoftschen Entwicklungszyklus vorweg.

Was lässt sich noch über die nächste Version von Visual Studio und .NET sagen, das andere nicht schon gesagt haben? Ist nicht bereits jede Neuerung durchgekaut? Erklärungsversuche und Bewertungen finden sich überall im Internet, ebenso Übersichten über Neues und Veränderungen [1] [2] [3]. Bemerkenswert ist allerdings, dass sie nicht mehr vollständig sind. Sie können es nicht mehr sein. Die Differenzen zwischen VB6 und der Vorgängerversion waren noch überschaubar und in ihrer Gänze für nahezu jeden Entwickler relevant. Das ist heute anders. Die .NET-Plattform ist so ausgedehnt, dass jeden Entwickler nur einen Bruchteil der Differenzen zur Vorgängerversion interessieren können und sollen. Das habe ich bei der Keynote von Scott Hanselman auf der VSone im Februar in München gemerkt: Fast eine Stunde hat er über Plattformfortschritte referiert – von denen mich kaum einer tangiert hat, weil es vor allem um die Webentwicklung ging.

Heute gibt es nicht nur Web- und Desktop-Entwicklung, sondern auch Mobile und RIA dazu. Und innerhalb der Client-Plattformen weitere Unterteilungen: WinForms versus WPF, ASP.NET versus MVC versus AJAX. Bei anderen Aspekten der Softwareentwicklung ist es ähnlich, zum Beispiel bei der Persistenz, bei der Kommunikation, der Extensibility oder der Sicherheit. Sie alle warten mit breiter API und eigener Terminologie auf, definieren Patterns und verschreiben Best Practices. Von den Tools mal ganz zu schweigen. Visual Studio ist kein Code-Editor mehr, sondern eine komplexe Maschine zur Herstellung von Code, unterstützt durch manuelle Eingriffe.

Unübersehbarkeit

Das soll aber keine Bewertung sein, sondern nur eine Feststellung. So ist es halt. Keine Geheimnisse, keine breite Relevanz von Neuerungen oder Änderungen mehr. Der wachsende Umfang der Plattform führt unweigerlich zu einer Spaltung der Entwicklergemeinde. Die will das zwar nicht so recht wahr haben – aber passieren tut es ihr trotzdem. RIA-Entwicklung mit Silverlight ist etwas anderes als ASP.NET-Programmmierung. Skalierbare Verteilung ist etwas anderes als Datenzugriff mit dem Entity Framework. Wer fit werden will in der parallelen und asynchronen Programmierung, dem gelingt es kaum noch, sich auch noch tief mit .NET Security auseinanderzusetzen.

Wir kommen nicht daran vorbei, dass die Schnittmengen zwischen Entwicklern kleiner werden – und das Halbwissen nimmt leider zu. Das ist heute schon groß. Ein Beispiel: Die Zahl der Entwickler, die erklären können, wofür "yield return" in C# nützlich ist und wie es intern funktioniert, ist minimal. Ich habe das auf mehreren Entwicklerveranstaltungen abgefragt. Und das nach fünf Jahren, die es das Sprachfeature gibt. Es geht nicht um einen Aspekt einer obskuren API, sondern um eine Funktion des Hauptwerkzeugs der meisten .NET-Entwickler, ihrer Programmiersprache. Wie lange wird es da dauern, bis die anstehenden Neuerungen wirklich breit verstanden sind?

Nice to have

Ich kann mich natürlich an Kleinigkeiten erfreuen, etwa daran, dass es nun einfacher wird zu prüfen, ob eine Enum-Variable bestimmte Flag-Werte enthält [4]. Das war bisher nur nervig mit Bitoperationen festzustellen. Oder endlich gibt es eine Methode, um einen Stream zu kopieren [5]. Aber das bringt die Community nicht voran.

Dasselbe denke ich über Funktionen wie "Call Hierarchy" [6] oder "Generate From Usage" [7], die nett und nützlich sind, aber kaum mehr. Vor allem, weil Microsoft sich mit ihnen nicht von Toolherstellern wie JetBrains unterscheidet oder sogar hinter ihnen herhinkt. Statt in Features zu investieren, die so tief in die Plattform eingreifen, dass nur Microsoft sie realisieren kann, oder so komplex sind, dass sie Microsofts Größe für die Entwicklung brauchen, investieren die Redmonder Ressourcen in "Aufhübschungen" von Visual Studio, die Gleichwertiges von anderen doppeln.

Aber das gilt nicht für alles, was in der nächsten Plattformiteration steckt. Die Generalüberholung von Visual Studio war sicherlich überfällig und nur von Microsoft zu leisten. So sieht man mit VS 2010 an der Oberfläche eine WPF GUI (Windows Presentation Foundation) [8], und in der Tiefe versucht Microsoft mit dem Managed Extensibility Framework (MEF) [9] die IDE zu einem Eclipse-Rivalen zu machen. Auch "große Techniken" wie die erneut überholte Workflow Foundation [10] verdienen die Aufmerksamkeit von Microsoft als Plattformhersteller.

Wirklich spannend finde ich jedoch auch das nicht. Sicher war es nötig, an diesen und anderen Stellen etwas zu tun. Wenn es nun zum Beispiel möglich ist, die clientseitigen IDs für ASP.NET-Steuerelemente besser zu beeinflussen [11], dann war das lang erwartet – aber fundamental ändert das nichts an der Plattform oder am Programmiermodell. Es dient dem Status quo.

Was Entwickler jedoch brauchen, sind grundsätzliche Veränderungen. Nach zehn Jahren .NET-Plattform ist es an der Zeit, fundamentale Probleme anzugehen. Als .NET neu war, hat es das getan. Garbage Collection, Managed Code, .NET Remoting, ASP.NET, Webservices, Code Access Security, Delegaten, Boxing waren wirklich neue Ansätze, zumindest für die damaligen VB- und C++-Entwickler. Damit hatte Microsoft auf grundsätzliche Probleme und Herausforderungen reagiert.

Danach galt es nachzubessern. Die große Neuerung hatte Microsoft mit .NET 1.1 etabliert. Seitdem sind die Releases im Wesentlichen Kommentare dazu. Viele technische Aufgaben der 1990er sind damit gelöst, und so ist mein Empfinden, dass die meisten neuen Features beispielsweise des Visual Studio Debugger [12] Luxusprobleme lösen. Sie und andere beruhigen Jammernde auf hohem Niveau.