Besser ist nicht immer gut

So sehr ich mich auch über die Resonanz gefreut habe, so hat mich doch gewundert, dass die Diskussion um die "beste" Programmiersprache wohl noch kein Ende gefunden hat. Ich bin immer wieder erstaunt darüber, mit welcher Vehemenz die Ansichten über die Vorzüge der Lieblingssprache vertreten werden. So wird gerne darüber diskutiert, dass dies oder jenes besser ist. Aber oft scheint dabei vergessen zu werden, was dieses "besser" überhaupt bedeutet.

"Die" beste Programmiersprache gibt es aus verschiedenen Gründen sicherlich nicht. Genauso wenig, wie es "das" beste Wetter geben kann. Allerdings kann man sehr wohl, bezogen auf ein bestimmtes Problem, der einen Programmiersprache den Vorzug vor einer anderen geben.

Einer der Gründe, warum man sich in einem Projekt für Java entscheidet, könnte an der umfangreichen Bibliothek liegen. Nimmt man beispielsweise das Thema IP-Netzwerke, so bietet hier Java eine extrem einfache Schnittstelle. Wer je unter Unix und C ein Socket bereitstellen musste, der weiß, wovon ich rede.

Das soll nicht heißen, dass Java hier die beste Wahl ist, sondern nur eine plausible Alternative darstellt. Denn unter Java lassen sich lange nicht alle TCP-Parameter so einstellen, wie man das vielleicht bräuchte. Das ist im Laufe der Zeit zwar immer besser geworden, sodass in den meisten Fällen tatsächlich keine Wünsche mehr offen bleiben, aber für bestimmte Bereiche ist die Java-Bibliothek immer noch nicht wirklich geeignet.

Andere Sprachen bieten natürlich auch einfache und gelegentlich deutlich mächtigere Schnittstellen zum Netzwerk an. Warum entscheidet man sich dann vielleicht doch für Java? Weil es Java geschafft hat, alles zu standardisieren. Standardisieren bedeutet auch für jeden etwas anderes, aber im Falle von Java bedeutet das wohl, dass ein standardisierter Teil in der Regel Bestandteil des Basisumfangs von Java ist. Das heißt auch, dass ich mich in der Regel nur um mein "Zeug" kümmern muss; alles andere ist dort, wo Java ist, schon da.

Für Perl beispielsweise gibt es für so ziemlich jedes Problem mehrere Antworten. Das CPAN, das Comprehensive Perl Archive Network, ist seit fast fünfzehn Jahren online und bietet heute 17.758 Module von 8168 Autoren. Damit stellt das CPAN bestimmt eines der größten, wohlorganisierten Bibliothekssammlungen dar. Leider bedeutet das aber auch, dass man sich zwischen verschiedenen Implementierungen zur Lösung eines Problems entscheiden kann und muss.

Die Vielfalt, die zunächst vorteilhaft erscheint, entpuppt sich aber schnell als zweischneidiges Schwert. Denn plötzlich spielen nicht nur die technischen Aspekte eine Rolle, sondern beispielsweise auch Autorenschaft, Lizenzfragen, Verfügbarkeit, Wartungsintervalle und Abhängigkeiten von Komponenten untereinander. Und diese Liste lässt sich beliebig verlängern.

Grundsätzlich hat man diese Probleme auch bei Java. Das eigentliche Problem kommt aber durch die große Zahl der Einzelkomponenten zustande. Mit Java bekomme ich eine umfangreiche Bibliothek, die in – sagen wir mal – 90 % der Anwendungsfälle mehr als ausreichend ist. Und ich muss mich nur ein einziges Mal bezüglich all der obigen Probleme damit auseinandersetzen und anschließend (praktisch) nie wieder.

Es geht also gelegentlich nicht nur um den Inhalt, sondern auch um die Verpackung. Was in einer Produktionsumgebung verfügbar ist, kann demnach eine entscheidende Rolle spielen. Gerade in den Zeiten, wo man sich so wenig wie möglich um das zugrunde liegende System kümmern möchte, mag das eine besonders große Rolle bei der Sprachauswahl spielen.

Eine Entscheidung für eine konkrete Bibliothek macht es zudem meist unmöglich, diese zu einem späteren Zeitpunkt gegen eine andere einzutauschen. Häufig sind die Ansätze zu kontrovers, die Modelle zu verschieden und der Stil zu uneinheitlich. Bei Java wurde deshalb – oft auf Kosten der Performanz – eine einheitliche, abstrakte Schnittstelle geschaffen, für die es unterschiedliche Implementierungen, auch verschiedener Hersteller, geben kann.

Mit .NET gibt es jetzt übrigens eine vergleichbare Alternative. Aber diese beiden Techniken – Java und .NET – sind diesbezüglich relativ allein. Ich möchte hier noch einmal betonen, dass dies an und für sich kein Qualitätsmerkmal, sondern nur eine wertfreie Eigenschaft ist, die bei etwaigen Entscheidungen in die jeweiligen Waagschalen gelegt werden kann. Erst durch definierte Ziele bekommen diese Eigenschaften überhaupt eine Wertung.

Die "Features" von Sprachen selbst sind bei dieser Betrachtung noch überhaupt nicht eingeflossen. Vielleicht traue ich mich da noch nicht so richtig, ist doch das Risiko, vom Mob gelyncht zu werden, dort deutlich größer. Allein die geschweiften Klammern und deren Positionierung zu erwähnen könnte zu einem überraschenden, deutlich verfrühten Ende führen. So soll das lieber ein anderes Mal diskutiert werden. ()