Ein kritischer Kommentar zur Sprachenvielfalt in der Softwareentwicklung

Lasst uns schöpferisch sein und ein paar Programmiersprachen erfinden!

Beim Überfliegen der IT-News stolpere ich in letzter Zeit immer häufiger über Titel wie „Java als Plattform wertvoller als die Programmiersprache“, „Fünf Gründe, warum man gerade jetzt eine neue Programmiersprache lernen sollte“ oder „Not staying current as a software developer is software malpractice“. Ständig lese ich von neuen Programmiersprachen, „Frameworks“ (ist für mich das Unwort 2009) und Bibliotheken. Bei der JavaPosse.com haben Groovy- und Scala-Nachrichten schon lange ihren fixen Platz – jetzt muss aber langsam auch Platz für „Fan“ gemacht werden.

Letztere Sprachneuheit wird aber schon wegen der Namensgebung keinen Erfolg haben, finde ich doch in Google ganz viele andere Dinge – von Ventilatoren bis hin zu diversen Fan-Pages von Popsängern etc. Ebenso eine recht neue Sprache ist „PCASTL“ – auch da würden Marketing-Leute so ihre Freude haben (ich hab das zuerst wie „PC-Kastl“ gelesen).

Aber es gibt auch wieder Ansätze zu „Rapid Application Development“ (RAD), z.B. mit UniPaaS (das ist ein Nachfolger von Magic II, mit dem ich in den späten 80ern und frühen 90ern gutes Geld verdient habe – war wirklich effizient und ging nebenher mit der Schule). Oh, weil ich gerade von RAD spreche: Das ist doch eigentlich gar nicht mehr aktuell, habe ich geglaubt. „Extreme Programming“ oder „Agile Software Development“ sind doch gerade die Renner, oder? Naja, bei agiler (= flink, gelenkig) Softwareentwicklung denke ich sowieso erst einmal eher an planloses Vorgehen – so frei nach dem Motto „mal schnell was zusammenklicken“.

Bevor ich jetzt Scala oder Fan lerne, so dachte ich mir, schau ich doch mal auf Wikipedia nach, vielleicht habe ich ja noch etwas ganz besonders Modernes und Ultimatives übersehen. Erspart euch den Weg zu Wikipedia, die Liste dort ist einfach nicht vollständig! Einen besseren Eindruck bekommt man auf 99-bottles-of-beer.net. 1290 (!!!) Programmiersprachen sind dort verzeichnet, mit Beispielen, und da kommen die vorher erwähnten Sprachen Magic II und UniPaaS beide nicht vor! Also ist auch diese Liste nicht vollständig: Wir sind somit in einer ähnlichen Lage wie die Biologen, die in entlegenen Winkeln der Erde auf der Suche nach neuen Spezies sind.

Aber wisst ihr eigentlich, was das heißt? Im Durchschnitt über 19 neue Programmiersprachen pro Jahr (ich habe jetzt ab 1943 gerechnet, da fängt es mit den ersten wirklichen Programmiersprachen an). In Worten: neunzehn neue pro Jahr!

Die IT ist doch wirklich eine tolle Branche! Während in den 80er-Jahren die Leute Angst hatten, die EDV würde ihre Jobs ruinieren, hat sie doch in Wirklichkeit eine ganze Menge Jobs geschaffen! Und nicht nur das: In Zeiten, in denen Selbstverwirklichung einen hohen Stellenwert hat, möchten sich viele nicht mehr mit Routine-Arbeiten abmühen sondern kreativ sein: Also lasst uns schöpferisch sein und ein paar Programmiersprachen und Frameworks erfinden!

Dann brauchen wir eigentlich bald einen „Software Development Consultant“, der uns berät, welche Komponente unseres nächsten Projektes wir am besten mit welcher Sprache schreiben – einen guten Psychiater kann er uns auch gleich empfehlen, der mit Programmierern schon Erfahrung haben sollte!

Während im düsteren IT-Mittelalter die Standard-Bibliotheken einer Programmiersprache in den meisten Fällen noch halbwegs überschaubar waren, muss eine Sprache, die sich heute durchsetzen will, schon mit umfangreicherem Handwerkszeug ausgestattet sein. Eine ordentliche Entwicklungsumgebung (IDE) und ein WYSIWYG-GUI-Designer gehören da eigentlich auch dazu. Und da haben wir auch schon eine Crux, wenn wir auf die ganz neuen Sprachen setzen wollen: Im Allgemeinen müsste ich dann nämlich auf reine Text-Editoren ohne Syntax-Highlighting und Auto-Completion zurückgreifen. Das ist wirklich tiefstes Mittelalter für mich (ich weiß, die wirklich harten Programmierer haben es nie anders gemacht). – Also, ran ihr fleißigen Programmierer, für die – sagen wir mal – drei gängigsten Entwicklungsumgebungen gehören noch Plug-ins für die 19 neuen Programmiersprachen des heurigen Jahres programmiert. Das sind gerade mal 57, ist doch ein Klacks!

Nun, die wirklichen Insider unter Euch werden mir jetzt sicher sagen, dass sich ja von all diesen Sprachen nicht alle auch wirklich durchsetzen werden. Aber der Nebel auf meiner Glaskugel will sich nicht so recht lichten, und ich bin auch nicht mehr so wahnsinnig, bei richtigen Projekten ein Versuchskaninchen auszulassen. Ich denke, es gibt einen Bereich in der IT-Entwicklung, den man wirklich den Universitäten überlassen sollte: Forschung an der Programmiersprache. Es gibt sogar einen eigenen Forschungsbereich für IT-Philosophie (Roy Thomas Fielding gehört zu denen).

Aber wenigstens ein paar Sprachen sollte man doch können, oder? Es hätte den Vorteil, dass man – Gott behüte – nach einem schweren Unfall wahrscheinlich nur mit einem Teilverlust seiner Programmierkenntnisse zu rechnen hätte (sagt die Wissenschaft, weil das Gehirn unterschiedliche Sprachen an verschiedenen Orten im Gehirn speichert). Also Groovy war vor kurzer Zeit noch ein wirklicher Kandidat. Das hätte ich mir fast schon angeschaut – aber mittlerweile sagt sogar der Erfinder, dass er Groovy nicht erfunden hätte, wenn es Scala schon gegeben hätte. Ach ja? – Wieso steht dann auf Wikipedia in der Zeitlinie der Programmiersprachen Scala (2003) vor Groovy (2004)? Vielleicht hätte Martin Odersky (Erfinder von Scala) etwas mehr Aufsehen erregen müssen, um den Bekanntheitsgrad rechtzeitig zu steigern (aber für Marketing steht den Universitäten in der Regel nun einmal kaum Budget zur Verfügung).

Zurück zur Vernunft

Es würde helfen, wenn man einige der Energien bündelte und sich ein paar Leute zusammensetzen würden, um nun einmal wirklich eine ordentliche Programmiersprache zu entwerfen. Aber bitte dann auch gleich die Entwicklertools dazuschreiben, sonst bringt mir das wieder nichts. Eine coole Syntax ist nur ein Bruchteil dessen, was ein Entwickler so braucht.

Und eines darf man auch nicht vergessen: Wie schön auch eine neue Programmiersprache sein mag: Es dauert mindestens ein Jahr, bis man mit einer neuen Sprache wirklich produktiv wird.Völlig überflüssig daher, alle zwei Jahre mal wieder eine neue Sprache zu lernen.

„Wenn man einen Hammer hat, schaut alles wie ein Nagel aus“, höre ich oft als Argument. Ich soll doch bitte für jedes Projekt je nach Anforderung auch die am besten passende Programmiersprache auswählen, um das Problem zu lösen. Eine solche Vorgehensweise führt mit der Zeit unweigerlich zu einem Wildwuchs von Programmiersprachen innerhalb einer Firma oder sogar innerhalb eines einzelnen Software-Produktes. Dann braucht man natürlich wieder Mitarbeiter, die sich mit all diesen Sprachen auskennen sollten.

Fakt ist doch, dass eine Programmiersprache eigentlich für möglichst alle Bereiche geeignet sein sollte und dass niemand in allen Sprachen gleich gut sein kann. Jemand, der nur eine Sprache kann, die aber sehr gut, ist im Allgemeinen produktiver als jemand, der wegen kleiner Vorteile immer wieder die Programmiersprache wechselt. Schon aus dem Gesichtspunkt der Wiederverwendbarkeit von Code-Teilen und Komponenten sollte das klar sein. Man tut eben gut daran, den ROI (Return Of Investment) zu berücksichtigen.

Es liegt eigentlich auf der Hand, dass es – wie bei einer „richtigen“ Sprache auch – effizienter wäre, sich auf eine Sprache zu einigen, die dann alle verwenden, sodass sich alle untereinander besser verstehen können. Auch in der richtigen Sprache gibt es eine Tendenz zur Standardisierung (z.B. Englisch als Konzernsprache). Dabei ist es wichtig, dass diese Sprache vom Konzept her gut und einfach ist. Sie sollte ja auch vom Nachwuchs schnell erlernt werden können, was wohl auch nicht bei allen 11 aktuellen Weltsprachen der Fall sein dürfte (da sind einige auch gar nicht „IT-freundlich“). Man stelle sich nur vor, man könnte überall auf der Welt hinreisen und sich mit den Leuten überall verständigen – ein Traum wäre das…

Für die tägliche Programmierarbeit ist es mir wichtig, dass ich mich auf die Sprache und die Entwicklungsumgebung verlassen kann, in dem Sinne, dass mir für Desktop-Anwendungen wie auch für Web-Anwendungen Technologien zur Verfügung stehen, die ich schnell und effektiv einsetzen kann und mir die Entwicklungsumgebung dabei nicht um die Ohren fliegt. Für die gängigen wie für die etwas spezielleren Anliegen sollten Bibliotheken zur Verfügung stehen, die ich verwenden kann. Außerdem möchte ich mir keine Gedanken darüber machen müssen, ob sich in den nächsten Jahren weiter Windows oder doch Apple oder letztendlich Linux mehr durchsetzen wird: Meine Programme sollen da und dort und drüben lauffähig sein (Stichwort Investitionssicherheit). Dabei zahle ich auch einen Preis, nämlich dass sich z.B. eine nahtlose Integration in Microsoft-Office-Produkte wohl etwas schwieriger darstellt (aber perfekt ist die Welt in der Softwareentwicklung – wie auch in der gesamten IT-Welt – eben bei weitem noch nicht).

So, was war noch gleich das nächste Thema – Frameworks oder doch Linux-Distributionen?

Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.