Eine für Alles, Alles in Einer

Wie regelmäßige Leser meines kleinen Blogs sicher schon festgestellt haben, ist eines der Gebiete, für die ich mich interessiere, das der Programmiersprachen. Welche Möglichkeiten gibt es in den verschiedenen Programmiersprachen und wozu kann man sie sinnvoll einsetzen?

Diesmal geht es mir um das Wachstum von Sprachen. Was man immer wieder sehen kann, ist, daß eine Sprache klein und einfach zu erlernen anfängt und dann immer weitere Bereiche gefunden werden, wo es doch so schön wäre, wenn man die Sprache ein klein wenig erweitern würde, damit dieses oder jenes vereinfacht würde. Es gibt natürlich auch die Sprachen, die gleich ganz groß angefangen haben: ADA und PL/1. Die erste wird von kaum jemandem freiwillig benutzt. Sie ist aber Voraussetzung in Ausschreibungen von militärischen Anwendungen. Wenn man sie mal begriffen hat, soll sie gar nicht so schlecht sein. Die zweite sollte mal Cobol ablösen. Sie hat aber die meisten Entwickler von Anfang an abgeschreckt und ist rasch in einer Nische verschwunden.

Sprachwachstum

Auch Java ist im Laufe der Zeit gewachsen und in den Diskussionsrunden der Gemeinde der Java-Entwickler bemerkt man die Wachstumsschmerzen. Allerdings ist Java im Wachstum gehemmt, da es lange dauert, bis ein JCP sich durchgesetzt hat. Anders ist das bei C#. Hier steht kein kompliziertes Gremium dahinter sondern die Entwickler der Sprache werden nur durch die Marketingabteilung getrieben. Eigentlich mag ich die Sprache. Sie ist zwar Java sehr ähnlich, konnte aber schon zu Beginn von einigen Jahren Erfahrung mit Java profitieren und einiges besser machen. Allerdings sind einige neue Ideen zuerst nur halbherzig implementiert worden und erst im Laufe der Zeit brauchbar geworden. Wie in Java haben es die Entwickler nicht hinbekommen, echte Closures in der ersten Version zu implementieren. Während in Java bis zur jetzigen Version nichts in dieser Richtung da war, hatte C# zu Beginn eine halbherzige Lösung namens delegate. Diese wurde erst in der zweiten Version brauchbar und in der dritten richtig rund.

Daneben gab es in der dritten Auflage der Sprache ein Feature namens LINQ. Dazu wurde die Sprache so verbogen, daß funktionale Konzepte wie Monaden darin untergebracht worden konnten. Die Prototypen wurden in F#, einer funktionalen Sprache für das dotnet Framework, entwickelt und dann zu C# migriert. In meinen Augen hat LINQ bislang nicht viel Gutes gebracht. Es hat die Sprache aufgeblasen, verhindert aber die Portabilität von Lösungen, die darauf aufbauen. Die Datenbankanbindung funktioniert nur für SqlServer. Für Oracle gibt es keinen Support und wohl auch keine wirkliche Nachfrage. Noch schlimmer ist, daß Microsoft wegen LINQ die Unterstützung von XQuery in seinen Produkten nicht weiterentwickelt hat. XPath und XSL sind auf der Version 1 stehengeblieben, während der Rest der Welt beginnt, sich an den neuen Möglichkeiten der Version 2 zu erfreuen. Jetzt droht die vierte Auflage. In seinem Blog zeigt sich der erfahrene C#-Trainer Frank Quednau einerseits erfreut über die neuen Möglichkeiten, andererseits bezweifelt er, daß die Sprache dann noch in einem einwöchigen Kurs unterrichtet werden kann. Das ist für mich aber ein ganz großes Problem. Das bedeutet, daß es dann schwer sein wird, in einem größeren Projekt genügend Leute zu finden, die die Sprache vollständig beherrschen. Dann beginnen wieder die projektinternen Vorschriften, welche Sprachkonstrukte nicht benutzt werden dürfen. Wir kennen das von C++. Dies ist für die fortgeschrittenen Programmierer frustrierend, da sie sich gezwungen sehen, in ihren Augen schlechteren Code zu schreiben, nur damit das durchschnittliche Teammitglied eine Chance hat, diesen zu verstehen. Allerdings wird dieser Code dann auch nicht gerade schöner, denn wie das Gehirn nun mal arbeitet, werden dann nicht Lösungen implementiert, die zu den eingeschränkten Möglichkeiten passen, sondern Rückportierungen der neuen Konstrukte.

Mehrsprachlichkeit

Gerade bei dotnet ist es eigentlich überhaupt nicht notwendig, alles einer Sprache aufzubürden. Die Grundidee war eigentlich, daß sich verschiedene Sprachen eine Umgebung teilen können, in der Komponenten, die in den unterschiedlichen Sprachen geschrieben werden, zusammenarbeiten. Das funktioniert ja auch ziemlich gut, so gut sogar, daß die Java-Welt nach anfänglicher Ablehnung dieses Konzept jetzt begeistert übernommen hat. Warum macht man es sich das nicht zunutze und entwickelt verschiedene kleinere Sprachen, die für den jeweiligen Anwendungsfall optimiert sind? Dies gilt ganz besonders für Sprachkonstrukte, die offensichtlich überwiegend für Codegenerierung entwickelt wurden. Der normale Entwickler braucht doch nicht die Dinge zu kennen, die die diversen Wizzards in VisualStudio verwenden. Schon dadurch hätte die Sprache entschlackt werden können.

Auch wenn man dann mehr Programmiersprachen kennen muß, so hat doch jede ihren Kontext. Mehrere Programmiersprachen sind für heutige Projekte ja sowieso schon die Normalität. SQL, HTML, XSL etc. werden neben der Hauptentwicklungssprache meist noch verwendet.