Evolution Rohdokument

Mein Entwurf des Artikels Link to heading

Gemini in die Rolle eines Lektors bringen Link to heading

Hallo, ich könnte Deine Hilfe als Lektor für einen Blog Artikel gebrauchen. Dabei soll es um die Schwierigkeiten der multiparadimatischer Programmierung gehen, die durch Konflikte zwischen objektorientierter und funktionaler Denkweise entsteht

Mein Rohartikel Link to heading

Paradigmenwechsel gefällig ?

Als Coder habe ich über 50 Jahre Software erstellt und einige Paradigmen und deren Hypes erlebt.

Wie die meisten habe ich imperativ angefangen. Erst mit dem Taschenrechner, dann über Zilog Z80-Maschinencode zum Assembler, im Studium lernte ich, mittels Pascal strukturiert zu programmieren.

Dessen Erfinder Niklaus Wirth, blieb mir mit folgender Aussage in Erinnerung, dessen tiefere Bedeutung mir erst viel später klar wurde:

Whereas Europeans generally pronounce my name the right way (‘Ni-klows Virt’), Americans invariably mangle it into ‘Nick-les Worth.’ This is to say that Europeans call me by name, but Americans call me by value.

Denn schon zu dieser Zeit entstand eine Kluft zwischen der Priorisierung von Werten/Daten und deren Zugehörigkeit zu ihrem Kontext, eine Kluft zwischen Mathematikern, Technikern und Ökonomen.

Informatikern mit mathematischem Background bevorzugten Lisp, die nach Fortran älteste Programmiersprache, eine symbolische Sprache. Mathematiker legen Wert auf Allgemeingültigkeit und erfanden Variablen, symbolische Namen statt konkreter Werte für ihre Formeln. In Lisp konnte man mit Formeln arbeiten, unabhängig von konkreten Werten.

Diese Kluft vertiefte sich - von den meisten Codern unbemerkt - durch die Objektorientierung und den scheinbaren Segen des “Erbens” von Werten in Objekten. Ich lernte damals erst Smalltalk, dann C++ und ein wenig Java. Im Job blieb davon überwiegend C++. Objektorientierte Hierarchien, besonders Vererbung und Polymorphismus erschien allzu natürlich, gerade grafische Bedienoberflächen, 3D-Objekt Hierarchien, CAD-Programme all das schien erst mit Objektorientierung richtig gut zu gehen und die Objekthierarchien wuchsen gigantisch und füllten jeden verfügbaren Raum im immer billiger werdenden wachsendem Arbeitsspeicher.

Aber die Gigantomanie hatte einen Preis und eine Ursache, weil das Wort “Vererbung” den wahren Charakter der Objektorientierung verschleiert. Vererbung heißt auch Spezialisierung und die ebenfalls gepriesene Datenkapselung entpuppte sich in dem Moment als riesiges Problem, als Nebenläufigkeit, Vernetzung bzw. Kommunikation von Anwendungen und Rechnern aufkam.

Das Verquicken von Werten und Funktion im Sumpf gigantischer Objekt - Bäume erschwerten die Reaktion auf Datenströme, welche die Aktualisierung jener versteckten Daten erforderlich machte, zumal allein schon die Verwaltung der gigantischen Objektmodelle sehr viel Speicher und Rechenzeit kostete.

Man sollte die Errungenschaft der Heredität (Vererbung) des Lebens auch als Ursache für das unvermeidliche Aussterben der meisten einst erfolgreichen Spezies sehen. Je mehr sich eine Art spezialisiert, desto wahrscheinlicher ist ihr Aussterben durch gravierende Veränderungen der Umwelt.

Jedenfalls musste sich die Informatik wieder an die funktionalen Wurzeln der zweitältesten Programmiersprache (Lisp) und deren Nachfolger erinnern. Dazu gehört auch der Erfolg des syntaktisch an den erfolgreichsten Vertreter der OOP angepassten und ansonsten sehr schlampig entworfenen Javascript, denn Javascript kann nicht nur Daten, sondern auch Funktionen als Werte übergeben und als Werte zurückgeben.

Damit wird es möglich, Code allgemeingültig, also unabhängig von bestimmten Werten zu machen und Datenströme durch den Objektbaum zu schleusen, welche alle Werte stets aktuell halten.

Mit neuen Programmiersprachen wie Scala, Kotlin, Dart und Go versucht man Kompromisse zwischen Vorteilen der Objektorientierung und dem Umgang mit nebenläufigen Datenströmen zu lösen, aber auch recht flexibel konstruierte Sprachen wie Python und Javascript und dessen Erweiterung TypeScript ermöglichen die Verwendung von Objekt - Hierarchien, die sich mit Datenströmen aktualisieren können.

In Rückbesinnung auf Niklaus Wirth, der gerne Einfachheit postulierte und die Gigantomanie bei der Software-Entwicklung tadelte, favorisiere ich persönlich mittlerweile Go als meine Lieblings-Programmiersprache. Niklaus Wirth drückte das so aus:

Software is getting slower more rapidly than hardware becomes faster.

Dem von Wirth angestrebten Weg zu schlanker, schneller und nicht zu komplexer Software befolgte auch Google’s Go-Team:

Ken Thompson und Rob Pike gehören zu den Vätern von Unix, dem Vorläufer aller unixoiden Betriebssysteme wie Linux, BSD und macOS. Die beiden entwarfen bei Bell Labs (das spätere AT&T) auch das experimentelle Betriebssystem Plan 9, mit dessen Tools Ken Thompson dann die erste Go-Version entwickeln konnte. Der Schweizer Robert Griesemer stieß von der ETH Zürich zu diesem Team, nachdem er bei Niklaus Wirth promoviert wurde und bei Google bereits an der Entwicklung der schnellen und kompakten Javascript V8-Engine.

Die minimalistische und auf Notwendiges begrenzte, schlanke Architektur, effektive Verarbeitung und Realisierung der Nebenläufigkeit von Go erinnert stark an Wirths objektorientiertes Oberon, mit dem sich Robert Griesemer bei der ETH beschäftigt hat. Go gilt zwar nicht als objektorientiert, weil es keine Klassen (wie inzwischen sogar in Typescript) gibt, aber dafür bietet es dank Interfaces (bei Go structs genannt) objektbasiertes Programmieren ohne Probleme mit geerbten Instanz- Werten, wenn Nebenläufigkeit wichtig ist. Das und die eingeschränkte aber recht schlanke Syntax senken die Lernkurve stark, wozu auch eine einheitliche, automatisierte Quellcodeformatierung beiträgt, was aber auch den Go Übersetzer sehr beschleunigt.

In weiteren Artikeln werde ich mich deshalb vor allem mit Go beschäftigen, denn meiner Meinung ist Go wie einst Wirths Sprachen Pascal, Modula und Oberon eine ideale Lernplattform für modernes Coding.