Die Landschaft der Programmiersprachen ist ein Gebirge, dessen Gipfel in unterschiedlicher Abstraktionshöhe über dem Normalnull des Maschinencodes liegen. Es ist noch jung und in ständiger Bewegung. Die konstant aufeinander zudriftenden Platten der Wünsche von Programmierern und Unternehmen sowie des mit der Hardware Machbaren türmen es auf. Programmierer wollen, dass ihr Hauptwerkzeug immer einfacher und gleichzeitig leistungsfähiger wird; Unternehmer wünschen sich Werkzeuge, die ihre Programmierer produktiver und deren Produkte wartbarer, verständlicher und flexibler machen. Begrenzt werden diese Wünsche durch die Leistungsfähigkeit der Rechner für die Programmiererteams.
Seit mehr als 50 Jahre reiben und schieben sich diese Platten nun schon und haben eine bunte Vielfalt an Programmiersprachen entstehen lassen. Zunächst waren die emporstrebenden Gipfel flach. Assemblersprachen abstrahierten nur wenig vom einzig ablauffähigen Maschinencode. Fortran und COBOL hatten aber schon den Anspruch, für bestimmte Problemdomänen das Abstraktionsniveau der Programmierung anzuheben.
C stellte demgegenüber im Grunde einen Rückschritt dar; Abstraktion wurde Effizienz, Allgemeingültigkeit und Portabilität geopfert – und setzte damit einen De-facto-Standard mit Auswirkungen bis heute. C++, Java und C# stehen in der Tradition von C, auch wenn ihre Abstraktionsniveaugipfel über dem von C und anderen General Purpose Languages (GPL) der Vergangenheit liegen.
GPLs, zu denen auch noch Visual Basic oder Smalltalk gehören, stellen aber nicht das «Dach der Welt» im Gebirge der Programmiersprachen dar. Über sie hinaus ragen die Gipfel der Domain Specific Languages (DSL). Reguläre Ausdrücke (Regex), SQL oder auch visuelle Designer für horizontale oder vertikale Domänen abstrahieren noch weit mehr vom ausführbaren Maschinencode. Das verlangt ihnen allerdings ein Opfer ab: Sie tauschen Abstraktion gegen Allgemeingültigkeit; sie wollen nur für einen sehr engen Problembereich möglichst einfach, produktiv und verständlich sein.
Wie sieht nun die Zukunft des Gebirges der Programmiersprachen aus? Es bleibt in Bewegung. Der Druck der Platten aufeinander hält an. Die Gipfel streben weiter in die Höhe. Den DSLs geben Entwicklungsumgebungen (IDE) wie Visual Studio einen Schub. Microsoft integriert immer mehr Designer in seine IDE. Dialoge, Webseiten, Datenbanken oder verteilte Lösungen: Der dafür nötige Code wird heute schon in visuellen Spezialsprachen «geschrieben». Aber das ist erst der Anfang, denn mit den DSL-Tools (http://msdn.microsoft.com/vstudio/DSLTools/) will Microsoft dazu ermuntern, eigene visuelle Sprachen für beliebige Problemdomänen zu entwickeln. Das Abstraktionsniveau für Code wird damit in den nächsten Jahren in vielen eng begrenzten Bereichen deutlich steigen.
Aber auch wenn immer mehr Code in DSLs «geschrieben» wird, so bleiben GPLs das grundlegende und allgemeine Handwerkszeug für die allermeisten Programmierer. Der Druck zwischen Wünschen und Möglichkeiten ist hier jedoch nicht minder gross, und so ist die Frage berechtigt, wie sich die Gebirgsregion der GPLs entwickeln kann. Ein Rundflug über die älteren Gipfel in diesem Bereich führt von den prozeduralen zu den heutigen objektorientierten Sprachen. Die Spitzen der heute breit relevanten GPLs liegen allerdings dicht beisammen und bei allem Fortschritt im Hinblick auf das Abstraktionsniveau erstaunlich wenig über denen ihrer Vorläufer. Die in den 80ern in die Höhe geschossenen Gipfel einiger 4GL-Sprachen sind in Vergessenheit geraten oder durch die Kombination IDE+GPL unter dem Motto des Rapid Application Development (RAD) wegerodiert.
Die Entstehung eines neuen Gipfels kündigt sich an. Microsoft hat sich anheischig gemacht, das Abstraktionsniveau seiner .Net-Sprachen C# und Visual Basic deutlich anzuheben. Schon seit einiger Zeit sind Vorabversionen in Form von Community Technical Previews (CTP) online verfügbar (http://msdn.microsoft.com/data/ref/linq/) und erhitzen die Gemüter der Entwicklergemeinde. Denn das in Aussicht Gestellte verheisst einen wahrhaftigen Mont Blanc in der GPL-Gebirgsregion allerdings erst mit Erscheinen der nächsten Visual-Studio-Version «Orcas» irgendwann in 2007/2008. Mit dem bevorstehenden Release des .Net Framework 3.0 hat diese Entwicklung noch nichts zu tun.
Die zu erwartende Höhe des neuen GPL-Gipfels, der C# und Visual Basic deutlich über C++ und Java hinausragen lassen wird, machen sogenannte Language Integrated Queries (LINQ) aus. Sie erlauben die Formulierung von Abfragen im Sinne der SQL select-Anweisung innerhalb einer GPL. LINQ integriert damit die Welten der imperativen Programmierung und der deklarativen Abfragen. Objektorientierte und relationale Konzepte werden vereint.
4 GLs hatten eine solche Integration von (persistenten) Datenquellen mit GPLs auch schon versucht – konnten sich aber nicht durchsetzen. Ihre Basis war zu schmal, die Ansätze zu proprietär. Da nun Microsoft als Hersteller einer etablierten Entwicklungsplattform und Führer einer riesigen Entwicklergemeinde sich mit massivem Einsatz darauf wirft, ist mit einem (mittelfristigen) Erfolg zu rechnen. In jedem Fall ist LINQ als Nachfolgetechnologie zweier ObjectSpaces-Anläufe anzusehen, dass es sich hier nicht um eine mit der heissen Nadel gestrickte Partikularlösung handelt. Denn Microsoft geht es mit LINQ um etwas sehr Grundsätzliches: die Konsolidierung des Zugriffs auf alle Arten von Datenquellen.
Die Vision hinter LINQ ist die Vereinigung einer ständig wachsenden Zahl heterogener Datenquellen unter einem Programmiermodell für die fundamentale Datenselektion. Programmierer wollen alle Datenquellen durch die Brille der Objektorientierung (OO) sehen, und heutige Hauptspeicher erlauben die Präsenz grosser Datenmengen in Form von Objekten. Einzig die immer wieder notwendige Überwindung des Impedance mismatch zwischen OO-Datenmodell und den Datenmodellen der vielen Datenquellen sowie die grosse Verschiedenartigkeit der APIs für die Datenbeschaffung stehen diesem Wunsch entgegen bis jetzt.
LINQ räumt damit auf. Denn LINQ bietet deklarative, objektorientierte Abfragen auf heterogenen Datenquellen. Als einfachstes Beispiel einer Datenquelle mag ein Zahlenfeld dienen:
Mit einer C#-LINQ-Query unterscheidet sich der Zugriff darauf im Grunde nicht mehr von einer üblichen SQL-Abfrage wie select p from primzahlen where p > 2 and p < 11. Dass bei LINQ from vor select steht, ist dem Willen zur IntelliSense-Unterstützung innerhalb der Query durch die IDE geschuldet und ein vernachlässigbarer Unterschied. LINQ beschränkt solch intuitive Abfragen jedoch nicht auf Zahlenfelder. Der Code im Kasten 1 zeigt beispielsweise eine LINQ-Query auf dem Dateisystem. Diese Abfrage ermittelt alle DLLs im System32-Verzeichnis, die grösser als 0,5 MB sind, und gruppiert sie in Grössenschritten von 100 KB.
LINQ-Queries verbergen die Unterschiede in den APIs der vielen Datenquellen. Das macht den neuen Reiz der Orcas-Versionen von C# und Visual Basic aus. Wo O/R-Mapper-Werkzeuge bisher versucht haben, nur den Impedance mismatch zwischen OO-Sprachen und relationaler Welt zu überwinden, löst LINQ das allgemeine Problem des Mappings. Oder genauer: LINQ schafft eine Infrastruktur, in die Lösungen für das Mapping-Problem eingehängt werden können. Denn ein Garant für den Erfolg von LINQ ist seine Erweiterbarkeit. Microsoft hat nämlich nicht einfach die Syntax zweier seiner .Net-Sprachen um Abfrageklauseln erweitert, sondern baut sie selbst aus mehreren Spracherweiterungen auf, die auch für sich genommen wertvoll sind. LINQ ist insofern «nur» syntaktischer Zuckerguss – allerdings verführerisch süsser.
Dass die darunter liegenden grundlegenden Spracherweiterungen wie Extension Methods, Lamdba Expressions und Anonymous Types LINQ zu einer Plattform für jedermann machen, beweist Microsoft selbst mit zwei Erweiterungen: LINQ to ADO.NET (früher DLinq) und LINQ to XML (früher XLink). Sie ermöglichen die Abfrage von Datenbanken und XML-Dokumenten. Im Codekasten 2 ein Beispiel, das den Zugriff auf eine Datenbank zeigt.
Während LINQ-Abfragen auf Objektlisten wie der Menge aller Dateien in einem Verzeichnis direkt auf den Objekten ausgeführt werden, sorgen hier Klassen von LINQ to ADO.NET dafür, dass die LINQ-Abfrage zunächst in eine SQL-Query übersetzt wird. Nur die damit selektierten Daten aus der Datenbank werden dann zu Objekten gemacht. Aber diese Feinheiten sind dank Extension Methods und Lambda Expressions dem Programmierer verborgen. Und genau das ist die grosse Leistung von LINQ. Die äusserliche Gleichbehandlung unterschiedlichster Datenquellen lässt C# und Visual Basic eine neue Gipfelhöhe für GPLs erreichen. Denn hohes Abstraktionsniveau ist gleichbedeutend mit Vernachlässigung von Feinheiten und Fokussierung auf das Wesentliche. Genau das bietet LINQ: Nicht wie Daten genau beschafft werden müssen, ist wichtig für die Erfüllung funktionaler Anforderungen, sondern welche Daten benötigt werden. LINQ übernimmt das «Wie», der Programmierer formuliert nur noch das «Was».
Die Modularität von LINQ
