LINQ wird missverstanden!

In der Ausgabe 9 des dotnet magazins ( http://www.dotnet-magazin.de ) sind in der OpenStage Kolumne meine Gedanken zu LINQ abgedruckt. Nachdem der Artikel nun erschienen wird er auch hier "abgeblogged".

Mittlerweile habe ich schon dutzende Artikel und Vorträge zu LINQ gehört. Und immer wieder sehe am Inhalt der Vorträge und den Reaktionen, dass LINQ missverstanden wird. Auch die Innovatoren von LINQ tragen nicht gerade zur Klarheit bei. Ein typisches (schlechtes) LINQ-Beispiel ist:
From c in Customer Where c.City == “London“ Select c
Dieses Beispiel suggeriert, dass man es hier mit SQL zu tun hat. Zugegeben etwas verdrehtes SQL, das From steht vorne und das Select hinten, aber es sieht nach SQL aus. Die Assoziation die dabei unweigerlich beim Programmierer entsteht ist Folgende: Linq … SQL … Datenbank; Ah! Linq ist für Datenbanken bestimmt. Die ganze Power von LINQ verpufft in diesem Moment, wo LINQ mit SQL gleich gesetzt wird und auf die Verwendung von Datenbanken reduziert wird.
Liege ich mit meiner Einschätzung so falsch? Ein Blick in das LINQ MSDN-Forum zeigt, dass über 90% der Fragen auf die Verwendung von LINQ in Verbindung mit Datenbanken abzielen. Da wird von LINQ sogar als O/R Mapper gesprochen.
Auch die LINQ Queryoperatoren tragen nicht gerade dazu bei, dass man sich von SQL unterscheiden will. From, Select, Where - diese kennen wir alle von SQL. Was LINQ gerade auszeichnet, ist aber dass man alle Datenquellen befragen kann, also auch Objekte und XML etc.. Was vorher nur auf Datenbanken beschränkt gewesen ist, ist nun für andere Datenquellen möglich. Das ist das Revolutionäre an LINQ! Ein einheitliches Konzept um Daten abzufragen!
Natürlich muss auch ein einheitliches API für LINQ gefunden werden. Es kann schlecht sein, dass man um Datenbanken abzufragen eine andere Syntax verwenden muss, als für XML oder Objekte. Das hatten wir nämlich bisher: SQL für Datenbanken, XPath für XML und diverse Methoden für Arrays. Damit soll nun Schluss sein. Warum gerade aber LINQ so nah an SQL angelehnt ist, kann ich nicht verstehen. Vielleicht will man damit LINQ schneller etablieren. Langfristig gesehen wird man sich damit aber Probleme einhandeln. Wir können erwarten, dass mit der Zeit LINQ Implementationen für exotischere Datenquellen, auftauchen werden. Dann mag eine SQLnahe Syntax nicht mehr passend sein! Und dann sind wir bei dem Punkt angelangt, was LINQ eigentlich vermeiden wollte, nämlich fester Bestandteil einer Programmiersprache zu werden. Denn Programmiersprachen leben länger als APIs.