Evolution lektoriert durch Gemini 3

Von Gemini 3 vorgeschlagene Fassung des Artikels Link to heading

Antwort Gemini 3 Link to heading

Hallo! Das ist ein faszinierender Text, der eine Brücke von der Computer-Historie zur modernen Software-Architektur schlägt. Man spürt deine 50 Jahre Erfahrung – besonders die Anekdote über Niklaus Wirth ist ein exzellenter Aufhänger.

Als Lektor habe ich den Fokus darauf gelegt, die Argumentationskette zu schärfen: Warum genau beißen sich OOP und funktionale Ansätze bei Nebenläufigkeit? Ich habe zudem ein paar Begriffe präzisiert (z. B. Structs vs. Interfaces in Go), um die fachliche Tiefe zu wahren.

Hier ist mein Vorschlag für eine optimierte Fassung:

Geminis Vorschlag für diesen Artikel Link to heading

Paradigmenwechsel gefällig? Link to heading

Als Coder habe ich über 50 Jahre Software-Entwicklung und etliche Paradigmen samt ihrer Hypes miterlebt. Wie die meisten fing ich imperativ an: erst auf dem Taschenrechner, dann über Zilog Z80-Maschinencode hin zum Assembler. Im Studium lernte ich schließlich durch Pascal das strukturierte Programmieren.

Dessen Erfinder, Niklaus Wirth, blieb mir mit einer Aussage in Erinnerung, deren 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.

Schon damals entstand eine Kluft in der Priorisierung: Geht es um den Wert (die Daten) oder um deren Kontext (die Zugehörigkeit)? Es war ein früher Konflikt zwischen Mathematikern, Technikern und Ökonomen.

Die mathematische Wurzel: Symbolik statt Instanz Link to heading

Informatiker mit mathematischem Hintergrund bevorzugten oft Lisp – nach Fortran die älteste Programmiersprache. Als symbolische Sprache setzt Lisp auf Allgemeingültigkeit. Mathematiker erfanden Variablen als symbolische Platzhalter für Formeln, unabhängig von konkreten Werten. In Lisp arbeitet man mit Logik, bevor man sie auf Daten anwendet.

Der Aufstieg der Objektorientierung (OOP) Diese Kluft vertiefte sich – von vielen unbemerkt – durch den Siegeszug der Objektorientierung. Der vermeintliche Segen der “Vererbung” versprach Ordnung. Ich lernte Smalltalk, C++ und Java. Im Berufsalltag dominierte C++. Hierarchien, Vererbung und Polymorphismus erschienen natürlich: Ob grafische Oberflächen oder komplexe 3D-CAD-Strukturen – alles schien erst durch OOP beherrschbar. Die Objekthierarchien wuchsen gigantisch und füllten den immer billiger werdenden Arbeitsspeicher.

Das Problem der Spezialisierung Link to heading

Doch die “Gigantomanie” hatte ihren Preis. Das Wort „Vererbung“ verschleiert oft den Kern: Vererbung bedeutet Spezialisierung. Die gepriesene Datenkapselung entpuppte sich genau in dem Moment als Hindernis, als Nebenläufigkeit (Concurrency) und vernetzte Kommunikation zum Standard wurden.

Das Verquicken von Werten und Funktionen im “Sumpf” riesiger Objektbäume erschwert die Reaktion auf Datenströme. Wenn Datenströme eine Aktualisierung versteckter Zustände tief in einer Hierarchie erfordern, entstehen Race Conditions oder massive Performance-Verluste durch Locking-Mechanismen.

Man kann die Heredität (Vererbung) in der Biologie als Analogie nutzen: Je spezialisierter eine Spezies ist, desto anfälliger ist sie für das Aussterben bei Umweltveränderungen. In der Software-Welt ist die “Umweltänderung” heute die massive Parallelisierung.

Die Rückbesinnung auf funktionale Stärken Die Informatik musste sich wieder auf ihre funktionalen Wurzeln (Lisp) besinnen. Sogar das oft als “schlampig” kritisierte JavaScript feierte Erfolge, weil es Funktionen als First-Class Citizens behandelt: Funktionen können als Werte übergeben und zurückgegeben werden. Dies ermöglicht es, Code unabhängig von festen Instanz-Zuständen zu schreiben und Datenströme elegant durch Applikationen zu “schleusen”.

Moderne Sprachen wie Scala, Kotlin, Dart oder TypeScript versuchen, den Kompromiss zwischen OOP-Struktur und funktionaler Flexibilität zu finden.

Warum Go mein Favorit ist Link to heading

In Rückbesinnung auf Niklaus Wirth, der stets Einfachheit forderte und Software-Gigantomanie tadelte, ist Go heute meine bevorzugte Sprache. Wirth sagte treffend:

Software is getting slower more rapidly than hardware becomes faster.

Das Google-Team hinter Go – Ken Thompson, Rob Pike und der Wirth-Schüler Robert Griesemer – verfolgte diesen minimalistischen Weg. Go verzichtet bewusst auf Klassen-Hierarchien. Stattdessen nutzt es Structs für Daten und Interfaces für das Verhalten.

Dieses “objektbasierte” statt “objektorientierte” Design vermeidet die Probleme starrer Vererbungsketten bei der Nebenläufigkeit. Die schlanke Syntax senkt die Lernkurve enorm und sorgt (zusammen mit der automatisierten Formatierung) für eine extrem hohe Kompiliergeschwindigkeit.

Go ist für mich – wie einst Wirths Pascal oder Oberon – die ideale Lernplattform für modernes, effizientes Coding. In kommenden Artikeln werde ich tiefer in die Welt von Go eintauchen.

Geminis Rezension und Erklärung der Entwurfsänderungen Link to heading

Was ich für dich geändert habe:

Fachliche Präzision: In Go gibt es keine “Interfaces namens Structs”. Ich habe es so formuliert, dass Go Structs für Daten nutzt und die Entkoppelung über Interfaces löst.

Struktur: Zwischenüberschriften eingefügt, um den Text scannbar zu machen.

Wirth-Zitat: Das Zitat grafisch hervorgehoben (Blockquote), da es ein zentrales Element deines Textes ist.

Metapher-Check: Die Analogie zum Aussterben spezialisierter Spezies ist sehr stark – ich habe sie etwas prägnanter herausgearbeitet.