Suche

Programmieren macht heute keinen Spaß mehr

Hartmut Schlosser

Programmieren macht heute keinen Spaß mehr, sagt Eric Allman in seinem vielbeachteten Blogeintrag Programming Isn’t Fun Any More. Besteht der Großteil der Arbeit eines Java-Entwicklers nicht aus dem eintönigen Zusammenschustern von Bibliotheken, dem Einbinden von Frameworks und dem Refaktorisieren, Testen und Deployen von bestehendem Code?

Wo ist der Pioniergeist von früher geblieben, als man als Programmierer tatsächlich kreativ sein musste, um die logischen Probleme zu lösen, die derart vorher noch niemand vor sich hatte? Was ist mit der Faszination passiert, mittels einer mathematisch motivierten Sprache eine Maschine, also ein Haufen Blech, Plastik und Silizium, anzusteuern. Wo sind die Zeiten, als man noch das Gefühl hatte, das Handwerk – manche sagen die Kunst – der Programmierung voranzutreiben?

Reddit-Kommentator deong beschreibt die heutige Situation der Java-Community als Cargo-Kult: Statt direkt guten Code zu schreiben und zu deployen, deployet man lieber seine Lieblingstools, die das Problem für einen lösen.

Die Java-EE-Mentalität

Das Problem liege dabei nicht an der Sprache Java, sondern an einer gewissen Mentalität der Java-EE-Community, die besagt: Frameworks sind in jedem Fall ein Mittel, Komplexität zu reduzieren. Frameworks erledigen eine Aufgabe, die man sonst selbst kodieren müsste. Dass man sich damit eventuell einen riesigen Schwanz an Abhängigkeiten einhandelt, die nur schwer zu beherrschen sind, wird kritiklos akzeptiert.

Oftmals wird eine große Bibliothek oder ein ganzes Framework für das Erledigen einfachster Aufgaben eingebunden. Statt den Code lokal und damit einfach beherrrschbar zu halten, lagert man diesen immer mehr aus und begibt sich in Abhängigkeit „globaler“ und nicht mehr beherrschbarer Strukturen.

Architects trade local complexity for global complexity, and the bitch of it is, I can fix local complexity. It’s local. Go into the file or function, refactor it, clean up the variable names, etc. Global complexity kills you. deong

When ten lines of code are spread across a huge inheritance hierarchy with polymorphism replacing simple if statements, sequencing done by method chaining up the hierarchy, etc., and the data structures moved behind some opaque wall the framework puts up to keep your prying fingers away from them, there’s nothing you can do. That is a system that can’t be fixed. In a nutshell, the past 15 years or so of software engineering have been about ensuring that our inevitable errors are permanent and fatal. deong

Auf der Suche nach Einfachheit

Angesichts dieser Situation werden die Stimmen immer lauter, sich auf die alte Tugend der Einfachheit zurückzubesinnen. Wofür brauchen wir die aufgeblasenen Java-Tools und Frameworks eigentlich, die alles – und nichts – für einen erledigen? Historisch hat zwar das Spring-Framework tatsächlich Javas Beliebigkeit in Sachen Enterprise-Entwicklung behoben und einen ersten Fokus auf Einfachheit gelegt. Für Scala-Evangelist Dean Wampler ist dies jedoch erst der Anfang auf dem Weg zurück zur Einfachheit.

In seinem Blog Programming Can Be Fun Again plädiert er dafür, dass Funktionale Programmierkonzepte, wie Sie heute wieder en vogue sind, den nächsten Schritt darstellen können.
Mehr noch: Für Wampler hat der Paradigmenwechsel hin zur Funktionalen Programmierung bewirkt, den Spaß an der Arbeit wiederzufinden. Statt Framework- und Bibliotheks-Anpassungen vorzunehmen, hat er es bei Scala wieder mit der kristallklaren logischen Präzision zu tun, für die er sich als angehender Informatik-Freak früher einmal begeistert hatte.

So, for me, programming did become fun again when I started using functional programming as my main „paradigm“. It strips away the cruft, makes reuse actually work, keeps my code concise, and it appeals to the Math/Physics geek inside me that craves rigor and precision. Dean Wampler

Der akademische Pioniergeist

In den Diskussionen, ob neue Sprachen – Scala, Kotlin, Gosu etc. – denn nun schon reif für den Produktiveinsatz sind, kommt immer wieder das Argument zum Vorschein, die IDE-Unterstützung sei noch unzureichend, die Verfügbarkeit brauchbarer Bibliotheken nicht gegeben.

Nimmt man die obere Kritik an der Framework- und Tool-Verliebtheit der Java-EE-Community für bahre Münze, so offenbart sich interessanterweise, dass viele der Argumente gegen diese neuen Sprachen gerade aus der beschriebenen lethargischen Java-EE-Mentalität heraus angeführt werden. Wer sich stets auf Frameworks und Tools verlässt, wird mit Scala & Co wohl so seine Probleme haben.

Bezeichnen wird er die neuen Sprachansätze dann als „akademisch“ – und meint damit so etwas wie „weltfremd“. Vergessen hat er dann den Pioniergeist, der schließlich jahrzehntelang an den Universitäten anzutreffen war – und sicherlich heute noch ist! Einen Unterschied gibt es aber zu früher: Standen die akademischen Forschungen über lange Jahre hinweg hoch im Kurs und wurden von den führenden Köpfen der Informationsverarbeitung verfolgt, so scheint das Prädikat „akademisch“ in der heutigen Atmosphäre eher schon einen Makel zu bezeichnen:

Wer heute schreibt „Sprache X ist rein akademisch“, meint im Grunde: Was dort passiert ist irrelevant und eine Verschwendung an Ressourcen. Was diese Uni-Profs und subventionierten Sprach-Designer in ihren Elfenbeintürmen aushecken, ist ohnehin nicht industrietauglich.

Reddit-Kommentator deong hat sich angesichts dieser Situation aus der Industrie zurückgezogen und in die „Diaspora“ der akademischen Forschung begeben. Ein Weg, der sicherlich nicht für alle gangbar ist. Aber vielleicht hilft es schon, sich als Otto-Normal-Java-Entwickler mit den „akademischen“ Sprachen auseinanderzusetzen und zu evaluieren, welchen Nutzen diese jetzt schon in realen Projekten bringen können? Vielleicht kommt dann auch der Spaß am Programmieren zurück, bei einer Sprache, die alle für „rein akademisch“ halten.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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