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.

Fundamentale Veränderungen

Fundamentalfeatures

Kann ich nun aber gar kein gutes Haar an Visual Studio 2010 und .NET 4 lassen? Keine Bange, auch mir gefällt das neue Release. Aber womöglich aus anderen Gründen, als die meisten Entwickler heute interessieren. Die neue Version macht sich tatsächlich daran, Fundamentales zu verändern. Nicht mit einer Revolution, sondern mit einer Evolution. Sozusagen Side-by-side-Verbesserungen innerhalb der Plattform. Das ist gut. Es wird die Akzeptanz fördern, wenn auch dadurch die Adoptionsgeschwindigkeit relativ niedrig sein wird. Man kann ja immer noch anders.

Die dynamischen Typen [13] und die Dynamic Language Runtime (DLR) [14] gehören zu den fundamentalen Neuerungen. Immer noch finde ich sie zwar überbewertet, dennoch bedeuten sie eine grundsätzliche Veränderung. Eine ganze Klasse von Sprachen wird durch die DLR einfacher möglich und die Anbindung der riesigen Plattform Office erleichtert. Dynamische Typen stehen für eine andere Herangehensweise an die Softwareentwicklung. Weniger festgefügte Strukturen, mehr Ad-hoc-Entscheidungen, mehr Convention over Configuration [15]. Code wird damit in einigen Bereichen deutlich einfacher.

Der Preis für das Mehr an Einfachheit ist Unsicherheit. Erst zur Laufzeit stellt sich heraus, ob dynamische Bestandteile wirklich zusammenpassen. Aber nicht nur deshalb bin ich begeistert von den Code Contracts [16]. Sie fördern über dynamische Szenarien hinaus die Korrektheit von Software und dienen der deklarativen Prüfung von Bedingungen, unter denen Code seine Arbeit tun kann. Wenn die zur Laufzeit nicht erfüllt sind, gibt es eine präzise Meldung statt einer obskuren Fehlernachricht von irgendwoher aus dem "Codebauch". Sie machen das Bugfixing einfacher. Außerdem fördern sie das Nachdenken über Code, und das ist immer eine gute Sache.

Gerne würde ich sagen, dass auch die Task Parallel Library (TPL) [17], PLinq [18] und die threadsicheren Datenstrukturen [19] fundamentale Neuerungen sind. Aber so schön es ist, dass sie Aufnahme in .NET 4 gefunden haben, wirklich große Sprünge nach vorn sind sie nicht. Zugegeben, die Parallelisierung von Abfragen mit PLinq ist cool. Die TPL ist ein guter Schritt nach vorn gegenüber dem ThreadPool. Doch den Effekt, den diese lokal anwendbaren Funktionen haben können, halte ich in den meisten Fällen für überbewertet.

Mehr gefreut hätte es mich, die Reactive Extensions (Rx) [20] nicht nur bei Silverlight, sondern auch in .NET 4 zu sehen. Oder gar die fast schon betagte Concurrency Coordination Runtime (CRR) [21]. Denn beide erweitern beziehungsweise verändern Programmierparadigmen. Sie bringen fundamentale Hilfe, wo anderes nur Symptomkur ist. Mit ihnen hätten nicht nur Parallelverarbeitung im Kleinen, sondern auch Asynchronität auf breiter Basis und im Denken Einzug gehalten. Denn ohne dass Parallelität und Asynchronizität in der Architektur sichtbar werden, ist keine wirkliche Ausreizung der steigenden Prozessorkernzahl zu erwarten.

Lichtblick F#

Aber es gibt einen Lichtblick, und zwar die Funktionale Programmierung (FP) [22], repräsentiert durch Visual F# [23]. Dass sie nun endlich ein "first class citizen" in Visual Studio wird, ist zu begrüßen. Sie und einige kleinere Funktionen wie Covariance/Contravariance [24] und Tuples [25] sind für mich die wesentlichen Neuerungen in Visual Studio 2010 und .NET 4.

Die Objektorientierung ist aus mehreren Gründen an ihre Grenzen geraten. Große objektorientierte Systeme sind schwer wartbar und erweisen sich als sperrig bei der Verteilung und Parallelisierung. In den Bereichen steigen die Herausforderungen jedoch in den nächsten Jahren. Software wird größer und lebt länger, sie muss sich immer flexibler verteilen lassen und sie muss Mehrprozessorkerne ausreizen. Dazu bedarf es einer Veränderung des Denkansatzes. Für den steht die Multiparadigmensprache F#. Wo C# um Eigenschaften von Funktionalen Sprachen erweitert wurde und wird, ist F# schon lange – und kann darüber hinaus noch das, was C# auch kann.

C# wird noch genauso lange wie C++ die Entwickler beschäftigen und sich auch noch über .NET 4 hinaus weiterentwickeln. Ob C# aber eine saubere, einfache Sprachen bleibt, ist fraglich. F# stellt demgegenüber einen frischen Ansatz dar. Es ist ein Sprung nach vorn, wie VB und Java es waren – doch ohne einen Plattformwechsel zu erzwingen.

Nach Jahren der Forschung ist F# nun reif für den Projektalltag. Microsoft honoriert das und nimmt die Sprache als Gleichberechtigte in Visual Studio auf. Das ist wegweisend, und darauf freue ich mich wirklich. Deshalb zum Ende noch eine Leseempfehlung: Programming F# von Chris Smith. Ein Buch, das F# in verständlichen Worten auch dem pragmatischen C#- und VB-Entwickler nahebringt.

Gelesen habe ich es im kalten Winter 2010 und war gar nicht traurig darüber, dass die halbe Welt schon lange über das neue Feature des nächsten Release von Visual Studio gesprochen hatte. Die Aufgabe der Geheimnistuerei um Weiterentwicklungen der Plattform hat deutliche Vorteile.

Ralf Westphal
ist Microsoft MVP für Softwarearchitektur und freiberuflicher Berater, Projektbegleiter und Trainer für Themen rund um .NET-Softwarearchitekturen

Literatur & Onlinequellen

1. Tim Anderson; What's new in Visual Studio 2010 – more than you may realize
2. Mendhak; New Features in Visual Studio 2010 and the .NET Framework 4
3. Joy; Visual Studio 2010 features and advantages
4. Enum.HasFlag Method
5. Stream.CopyTo Method
6. Call Hierarchy
7. Generate from Usage
8. Jason Zander; A New Look for Visual Studio 2010
9. Managed Extensibility Framework
10. What's New in Windows Workflow Foundation
11. Rick Strahl, ClientIDMode in ASP.NET 4.0
12. What's New in the Visual Studio Debugger
13. Using Type dynamic
14. Dynamic Language Runtime Overview
15. Wikipedia, Convention over Configuration
16. Code Contracts
17. Task Parallel Library
18. Parallel Linq
19. Data Structures for Parallel Programming
20. DevLabs: Reactive Extensions for .NET
21. Concurrency Coordination Runtime Introduction
22. Wikipedia, Funktionale Programmierung
23. Visual F#
24. Covariance und Contravariance
25. Matt Ellis; Building Tuple
26. Chris Smith; Programmig F#; O'Reilly 2010

(ane)