Gegeben sei ein Webprojekt in nicht allzu ferner Zukunft, bei dem jetzt schon eingermassen klar ist, was gefordert wird – serverseitige Programmierung gehört dazu. Mit dem Glück, auf “der grünen Wiese” anfangen zu können, geht die Entscheidung für eine bestimmte Programmiersprache einher. Wie entscheidet man?
Aus dem Bauch ‘raus
Wenn man schon mit mehreren serverseitigen Web-Sprachen vertraut ist, dann kann man seinem Bauchgefühl nachgehen. Für diesen Entscheidungsweg spricht, dass er kurz ist – Zeit ist Geld. Und alles in allem wird man das Kindchen schon schaukeln, schließlich ist man Programmierer, gelle. — Was tun, wenn man noch keine oder nur eine Websprache spricht und dem Bauchgefühl misstraut?
In dieser Umgebung
Das Ziel, dass Dich wie der Polarstern führt, ist, den Job zu erledigen. Dein Programm wird auf einer Maschine ausgeführt – und die legt Dir mitunter Beschränkungen auf. Wähle eine Sprache, die vom Zielsystem unterstützt wird.
Hier und Jetzt
Mach’ Dir keine Gedanken darüber, wie es in X Jahren sein könnte. Kann sein, dass sich nichts ändert – ich arbeite gerade mit 10 Jahre altem php-Code und 15 Jahre altem Lotus Script. Kann sein, dass sich alles ändert. Man weiss es nicht. Sobald Du versuchst, auf alle Eventualitäten vorbereitet zu sein, kommst Du schnell vom Hundersten zum Tausendsten – und verlierst das oberste Ziel aus den Augen. Beachte die Sachverhalte, die in nächster Zukunft anstehen – geplanter Betriebssystemwechsel und neue Major-Releases der kritischen Komponenten. Wähle eine Sprache, die Dir Hier und Jetzt hilft.
Übergabe-Punkte aka Schnittstellen
Heute bringen serverseitige Programmiersprachen eine Vielzahl von Schnittstellen mit: zu Datenbanken, Verzeichnisdiensten, dem Dateisystem uvm. Beachte die Schnittstellen, die im Projekt gefordert werden und nicht im Standardumfang der Sprache enthalten sind. Beispiel Daten-Import von Buchführung, Controlling und Vertrieb, Daten-Export in ein proprietäres Tabellenkalkulations-Format. Gibt es dafür fertige Lösungen – und wenn ja, in welcher Sprache? Beachte nur die Schnittstellen, die das Projekt unbedingt braucht und die Du bezahlt bekommst. Wähle eine Sprache, die es Dir leicht macht, die notwendigen Schnittstellen zu bedienen.
DRY
Kann sein, dass der Kunde Komponenten mehrfach nutzen möchte. Zum einen erfüllen sie ihre Aufgabe im Internet. Zum anderen soll auch die Abteilung XY die Komponente nutzen, um diesselben Berechnung auszuführen. Wenn das eine Anforderung ist, dann wähle die Sprache, die es Dir leicht macht, diese Anforderung zu erfüllen.
Die wichtigen Aufgaben so leicht wie möglich
Ein Kriterium ist, dass die Sprache es Dir leicht macht, die grossen und zahlreichen Aufgaben mit wenig Aufwand zu lösen. Konkretes Bespiel: Der Htmlparser in python ist komfortabler zu bedienen als der in Java. Wenn ich absehen kann, dass ich viel Html-Daten verarbeiten muss, dann nehme ich also python. Natürlich kriege ich dasselbe auch in Java hin, aber das braucht dann mehr Zeit, weil ich mir Helferchen drumherum basteln muss.
Gibt es bereits fertige Komponenten, die Du einbinden darfst und kannst?
Babylon
Schiebe die Entscheidung für die Implementierungssprache lange auf. Entwickle die Konzepte zuerst in UML. So lernst Du die Anforderungen gut kennen. Wenn Du eine Anforderung verstanden hast, dann mach’ Dich auf die Suche nach einer Sprache, die es Dir einfach macht, diese Anforderung zu erfüllen. Richte Dein Augenmerk auf die komplizierten Anforderungen. Am Ende hast Du eine Liste mit Paaren von Anforderung und Sprache. Wie oft kommt welche Sprache vor? Wie wichtig ist die Anforderung? Strich drunter, Zusammenzählen, entscheiden.
Deine Freundin Juno
Du brauchst eine gute IDE, Beispiel Eclipse Juno (Stand 2012) für Java. Du brauchst einen Debugger. Du brauchst Dokumentation. Du brauchst einen automatisierten Build-Prozess. Du brauchst Tests. Wähle eine Sprache, die Dir das ‘drumherum leicht macht.
Java, Perl, PHP
Ich mag stark getypte Sprachen lieber als schwach getypte, weil ich damit unkompliziert erkennen kann, welche Art von Daten gerade bearbeitet werden. Bei Refactoring und Reengineering ist das Gold wert. Java ist meine Brot-und-Butter-Sprache, da geht immer ‘was, da kenne ich Tricks und Fallstricke, das mache ich seit n+1 Jahren. Wegen Perl sind mir schon viele graue Haare gewachsen – das lag aber wohl mehr daran, wie der Code strukturiert war als an der Sprache selbst. In PHP kann man erträglich objektorientiert entwickeln – der entstehende Code ist leider nicht hübsch. Perl und PHP sind ganz ok, aber nicht meine erste Wahl.
Ruby (on Rails)
Mit Ruby habe ich noch nie gearbeitet, aber die Texte auf der Website sind sehr vielversprechend. Es gibt eine grosse Menge Zusatzmodule und Ruby On Rails – “optimized for programmer happiness” – wenn das kein Versprechen ist! Habe den Quelltext von “omniauth 1.1.4″ überflogen – sehr hübsch! Augenfreunlich :-) Habe das “Getting started” durchgearbeitet. RoR ist toll. Zwar war die Installation auf meinem System nicht ganz so einfach, wie es die Anleitung nahe legt, aber schließlich schlage ich mich mit sowas schon lange herum – also kein echtes Problem. Einige Code-Stellen von “Getting startet” werfen Fehler auf meinem System, aber auch das ist mit Erfahrung und duckduckgo in den Griff zu kriegen. Habe einen Blick auf die API-Doku geworfen, um einem Fehler auf den Grund zu gehen – bin damit spontan zurecht gekommen. Ich bin RoR-kompatibel ;)
Es gibt nicht “die beste Sprache”. Es gibt aber die Sprache, die Dir bei Deinem Projekt am besten dient. Nutze die Chance, eine neue Sprache kennenzulernen und riskiere Verzögerungen wegen Unkenntnis und kindlich-putzige Konstrukte. Nutze Deine Muttersprache und riskiere Verzögerungen wegen Radneuerfindung.