Frühe Prägung und BASIC
Ende der 1980er Jahre hatte ich zwar noch keinen eigenen Computer, aber bereits ein großes Interesse für das Programmieren entwickelt. Diese Zeit hat meinen späteren Weg in die Softwareentwicklung entscheidend geprägt. Robert C. Martin beschreibt dieses universelle Erweckungserlebnis in einem seiner Vorträge sehr treffend:
There came a moment in your life when maybe you were in a store somewhere and you walked up to a Commodore 64 [...] and you typed a little BASIC program that would just print your name infinitely and you would go "YES! I am a god!" And you wanted to be a programmer.
Genau ein solches Erlebnis hatte ich ungefähr zu der Zeit, als ich den Film "War Games" zum ersten Mal sah. In einem Kaufhof stand vermutlich ein Commodore 64, es könnte aber auch ein 8-Bit-Gerät von Atari gewesen sein. Jedenfalls tippte ich meine ersten BASIC-Zeilen ein.
Da ich keinen eigenen Computer hatte, war ich auf die Stadtbibliothek angewiesen, die einige Bücher über Computer im Allgemeinen und Programmierung im Besonderen hatte. Diese Bücher verschlang ich regelrecht und begann, auf Papier zu programmieren – eine Praxis, die heute völlig ungewöhnlich erscheint, damals aber durchaus üblich war. Jedenfalls hoffe ich, dass sie mittlerweile unüblich ist. In meinem Informatikstudium musste ich Ende der 1990er Jahre leider in so mancher Klausur auf Papier programmieren. Einmal musste ich eine solche Klausur wegen eines fehlenden Semikolons (oder eines nicht als solchen erkennbaren) sogar neu schreiben (Syntaxfehler!).
BASIC war zu dieser Zeit die dominierende Programmiersprache und die erste Begegnung mit dem Programmieren für Millionen von Menschen. Der Commodore 64 hatte BASIC als eingebaute Programmiersprache direkt im ROM gespeichert, sodass direkt nach dem Einschalten des Computers mit dem Programmieren begonnen werden konnte.
Amiga, Demoszene, ARexx
1990 bekam ich meinen ersten eigenen Computer, einen Amiga 500, der technisch gesehen ein gewaltiger Sprung nach vorn war. Er war mit 512 KB RAM, einem Motorola-68000-Prozessor mit 7 MHz, drei Custom-Chips für hochauflösende Grafiken (bis zu 640 × 512 Pixel), vielen Farben (bis zu 4096 Farben gleichzeitig auf dem Bildschirm) und digitalem 4-Kanal-Sound ausgestattet und war seiner Zeit weit voraus.
Auf dem Amiga begann ich, mit AmigaBASIC zu programmieren, einer von Microsoft speziell für den Amiga entwickelten BASIC-Implementierung. AmigaBASIC bot neben den üblichen BASIC-Sprachkonstrukten auch eine leicht zu verwendende Programmierschnittstelle für die einzigartigen Grafik- und Soundfähigkeiten des Amiga. Mit den OBJECT-Befehlen war es beispielsweise einfach, bewegliche Objekte – sogenannte Sprites und Bobs – zu erstellen und zu animieren.
Als Kind dieser Zeit kam ich natürlich auch mit Cracktros in Berührung und später mit echten Demoszene-Produktionen. Die Demoszene ist eine internationale Computer-Kunst-Subkultur, deren Mitglieder sich darauf konzentrieren, "Demos" zu produzieren: eigenständige, manchmal extrem kleine Computerprogramme, die audiovisuelle Präsentationen erzeugen.
Die Wurzeln dieser Szene liegen in den Software-Crackern der frühen 1980er Jahre. Sie entfernten Kopierschutzmechanismen und fügten dabei Intro-Bildschirme (Cracktros) hinzu, um ihre Signatur zu hinterlassen. Aus diesem Wettbewerb um die beste visuelle Präsentation entstand eine internationale Gemeinschaft, die unabhängig von der Gaming- und Software-Sharing-Szene existierte. Und diese existiert noch immer und ist mittlerweile als immaterielles Kulturerbe der UNESCO anerkannt.
Solche beeindruckenden Produktionen wollte auch ich programmieren können. Also begann ich, mir zunächst C und dann Assembler beizubringen. Assembler war die Sprache der Wahl für Demoszene-Produktionen, da sie maximale Kontrolle über die Hardware bot und somit optimale Performance ermöglichte.
Meine Freunde waren damals alle 5 bis 10 Jahre älter als ich. Einige von ihnen waren in der Amiga-Szene sehr aktiv und betrieben beispielsweise Mailboxen (Bulletin Board Systems, BBS). Wir besuchten gemeinsam Demoszene-Events, wo ich mich mit anderen austauschen konnte und die lebendige Kultur dieser Zeit hautnah erlebte.
So richtig losging es für mich mit dem Programmieren aber erst auf meinem zweiten Computer, einem Amiga 1200 mit dem neuen Betriebssystem AmigaOS 3, das die Programmiersprache ARexx mitbrachte. In Bezug auf Hardwarenähe war diese zwar ein Rückschritt gegenüber Assembler, aber sie eröffnete völlig neue Möglichkeiten.
ARexx war eine speziell für den Amiga entwickelte Implementierung der REXX-Sprache. Besonders war, dass sich damit Software sehr einfach automatisieren und erweitern ließ. Dank des Multitasking-fähigen AmigaOS konnte jedes laufende Programm als "Host" für externe Befehle fungieren, wodurch ARexx zur idealen Makrosprache wurde.
In dieser Zeit schrieb ich einige Anpassungen und Erweiterungen für Mailbox-Software wie AmiExpress oder FAME (Final Amiga Mailbox Engine). Diese Programme bildeten das Rückgrat der damaligen Online-Kommunikation, noch Jahre bevor das Internet für Privatpersonen zugänglich wurde. Natürlich war ich das erste Mal "im Internet" per Modem und mit meinem Amiga 1200.
Diese praktischen Projekte lehrten mich wichtige Lektionen über Software-Entwicklung: wie bestehende Software erweitert wird, wie mit anderen zusammengearbeitet wird und wie wichtig sauberer, wartbarer Code ist. Bereits auf dem Amiga, auch bei Projekten, an denen ich allein arbeitete, verwendete ich eine Versionskontrolle. Als ich das erste Mal RCS, den Vorgänger von CVS, gezeigt bekam, war das ebenfalls ein Erweckungsmoment.
Der Weg vom papierbasierten Programmieren über die ersten BASIC-Schritte auf fremden Rechnern bis hin zu eigenen Computern und schließlich zu ernsthaften Projekten spiegelt die typische Entwicklung vieler meiner Generation wider. Wir lernten Programmieren nicht in strukturierten Kursen, sondern aus eigenem Antrieb, getrieben von Neugier und dem Wunsch, die Maschinen zu verstehen und zu beherrschen.
Meine Erfahrungen mit verschiedenen Programmiersprachen, von BASIC über C und Assembler bis hin zu ARexx, lehrten mich früh, wie wichtig es ist, für die jeweilige Aufgabe das richtige Werkzeug zu wählen. BASIC eignete sich für den Einstieg, Assembler für maximale Performance, C für systemnahe Programmierung und ARexx für Automatisierung und Integration. Jede Sprache hatte ihren Platz und ihre Berechtigung.
Diese frühen Jahre legten das Fundament für meine lebenslange Faszination für das Programmieren und prägten mein Verständnis dafür, dass gute Software nicht nur funktionieren, sondern auch elegant, erweiterbar und wartbar sein sollte.
Studium, OOP, PHP, PHPUnit
Auch wenn ich Mitte der 1990er Jahre auf meinem Amiga 1200 bereits manchmal in C++ programmiert hatte, so habe ich das Konzept des objektorientierten Programmierens erst im Informatikstudium an der Universität wirklich verstanden. Und das nicht in einer Vorlesung: Zwar haben wir Java "gelernt", aber weder objektorientiertes Denken noch objektorientiertes Programmieren. Wir haben in Java im Grunde genommen prozedural programmiert. Was objektorientiertes Programmieren wirklich bedeutet und wie in Java programmiert werden sollte, habe ich schließlich von und mit anderen Studierenden gelernt.
Heutzutage möchte ich nicht mehr ohne Objektorientierung Software entwickeln, wobei ich gerne Anleihen aus der funktionalen Programmierung, wie etwa Immutability, nutze. Die Unveränderlichkeit von Datenstrukturen hat sich dabei als unverzichtbares Werkzeug erwiesen. Immutability und die Verwendung von Funktionen ohne Seiteneffekte sind grundlegende Konzepte, die auch in der objektorientierten Welt ihre Berechtigung haben.
Kurz nachdem ich 1998 mein Informatikstudium begonnen und meinen ersten x86-basierten PC gekauft hatte, kontaktierte mich ein Grafiker, mit dem ich zuvor in der Amiga-Szene zusammengearbeitet hatte. Er entwarf nun Websites und fragte mich, ob ich für einen seiner Kunden eine Lösung mit Perl oder PHP implementieren könnte. Da ich in keiner der beiden Sprachen Vorkenntnisse hatte, entschied ich mich, beide auszuprobieren.
Ich versuchte zuerst Perl, gab aber – ich kann mich nicht mehr an den genauen Grund erinnern – nach wenigen Stunden auf. Innerhalb eines Wochenendes war ich jedoch nicht nur in der Lage, ausreichend PHP zu lernen, um die Anforderungen des Kunden zu erfüllen, sondern ich konnte das Projekt auch erfolgreich abschließen. Ich bin überzeugt, dass dies eher etwas über Perl und PHP als über mich aussagt.
Später abonnierte ich zunächst die deutsche und dann die englische PHP-Mailingliste. Aus dem Stellen von Fragen wurde schnell das Beantworten von Fragen. Es dauerte nicht lange, bis ich bei der Übersetzung des PHP-Handbuchs vom Englischen ins Deutsche half. Schließlich fing ich an, direkt an PHP zu arbeiten, manchmal, um Fehler zu beheben oder kleine Funktionen zu implementieren, meistens jedoch, um das Konzept und Design von PHP 5 zu diskutieren, an dem damals gearbeitet wurde.
Meine Reise mit PHPUnit begann im Jahr 2000, als ich im Rahmen meiner Arbeit mit JUnit an der Universität erstmals mit Unit Testing in Berührung kam. Die Idee für PHPUnit entstand aus einer Diskussion mit einem Professor, der bezweifelte, dass ein Tool wie JUnit für PHP implementiert werden könne. Diese Herausforderung war der Katalysator für das, was zu einem der wichtigsten Werkzeuge im PHP-Ökosystem werden sollte.
Im November 2001 traute ich mich schließlich, das Ergebnis von über einem Jahr Arbeit auf cvs.php.net als Teil des PEAR-Projekts mit der Welt zu teilen. Diese erste Version war bescheiden, aber sie legte den Grundstein für das automatisierte Testen von PHP-Code. PHPUnit basierte von Anfang an auf der xUnit-Architektur, die mit SUnit begann und durch JUnit populär wurde.
Später löste sich PHPUnit von PEAR und steht seitdem als eigenständiges Projekt unter BSD-Lizenz zur Verfügung. Diese Unabhängigkeit ermöglichte es mir, PHPUnit schneller zu entwickeln und besser auf die Bedürfnisse der PHP-Community einzugehen. PHPUnit etablierte sich schnell als Standard-Testing-Framework für PHP und wurde von großen Projekten wie CakePHP, Drupal, Symfony, WordPress und dem Zend Framework rasch übernommen. Diese breite Akzeptanz bestätigt die Notwendigkeit und den Wert automatisierter Tests in der PHP-Entwicklung.
Als ich mit PHP anfing, bestand das Deployment einer neuen Softwareversion darin, alle (geänderten) PHP-Dateien per FTP auf den Server zu laden. Es war auch nicht unüblich, per SSH und Vim direkt auf dem Server Dateien zu ändern. Mit der Zeit professionalisierte sich der Deployment-Prozess durch das Erstellen von Paketen, deren Verteilung und Installation sowie die Aktivierung neuer Softwareversionen. Durch die Aufteilung des Prozesses in diese voneinander getrennten Schritte wurde das Deployment nachvollziehbarer, robuster und flexibler. Mittlerweile werden natürlich oft keine Pakete mehr gebaut, sondern stattdessen direkt Container-Images verwendet.
Moderne Continuous-Integration-Pipelines haben diese Entwicklung weiter vorangetrieben. Diese automatisierten Workflows können nicht nur Tests ausführen, sondern auch den gesamten Software-Entwicklungslebenszyklus abdecken: vom Code-Push bis zum Deployment in die Produktivumgebung.
Zu Beginn meiner PHP-Laufbahn war es nicht üblich, Software automatisiert zu testen. Ich hoffe, ich übertreibe nicht, wenn ich behaupte, dass ich dafür verantwortlich bin, dass automatisierte Tests in der PHP-Welt heute zur Normalität geworden sind. In den meisten Fällen geschieht dies mit PHPUnit.
Im Laufe der Jahre wurden diese dynamischen Tests durch statische Tests mit Werkzeugen wie Phan, Psalm und mittlerweile PHPStan ergänzt. Ein modernes PHP-Projekt ohne statische und dynamische Tests sowie eine entsprechende Continuous-Integration-Pipeline ist heute undenkbar.
Softwareentwicklung im Wandel
Mit der Zeit hat sich die Art und Weise, wie Software entwickelt wird, grundlegend geändert. Dies betrifft nicht nur die Technik, sondern auch und gerade die Prozesse und die Architektur. Zunächst wurde Test-Driven Development wichtig, später Domain-Driven Design und inzwischen Event-Driven Systems.
Der Technologie-Stack wird immer größer und die Komplexität der Anwendungen sowie der Umgebungen, in denen sie betrieben werden, auch und gerade im Legacy-Kontext, steigt kontinuierlich. Um in der Softwareentwicklung starten zu können, muss eine Anfängerin oder ein Anfänger immer mehr wissen.
Als 1987 der Amiga 500 auf den Markt kam, hatte jede und jeder, die oder der sich dafür interessierte, die Chance, die Architektur dieses Computers vollständig zu verstehen, inklusive CPU und Custom Chips. Die Hardware war einfacher. Ich glaube nicht, dass das für moderne Computer gilt, bei denen wir separate CPUs in unseren CPUs und manchmal sogar separate CPUs in anderen Hardwarekomponenten haben. Nun, wir sagen ja nicht umsonst, dass in der Softwareentwicklung alles rekursiv ist. Warum also nicht auch bei der Hardware?
Früher war aber nicht nur die Hardware einfacher. Auch die Art und Weise, wie wir Software entwickelt haben, war einfacher. Heute stehen wir vor ganz anderen Herausforderungen. Agile Methoden sind gut, und wir sprechen mit unseren Kundinnen und Kunden. Aber wir machen heute so viel mehr als nur programmieren. Wir übernehmen fast alle anderen Aufgaben, was sinnvoll ist, weil es uns näher an das Business bringt und uns dabei hilft, die richtigen Dinge schneller zu liefern. Aber es setzt uns als Entwicklerinnen und Entwickler auch enormen Druck, uns um alles zu kümmern, was früher von anderen Spezialistinnen und Spezialisten erledigt wurde.
Die Entwicklung von den einfachen Anfängen auf dem Amiga 500 bis zu den komplexen, modernen Softwarearchitekturen spiegelt die dramatische Veränderung unserer Branche wider. Was einst mit einfachen Deployment-Methoden per FTP begann, ist heute hochkomplexe CI/CD-Pipelines mit automatisierten Tests, Container-Orchestrierung und Event-Driven-Architekturen.
Die Herausforderung für heutige Entwicklerinnen und Entwickler liegt nicht nur in der technischen Komplexität, sondern auch darin, dass sie als Generalistinnen und Generalisten in einem Umfeld arbeiten müssen, das früher von Spezialistinnen und Spezialisten geprägt war. Während die universitäre Ausbildung weiterhin fundamentale Konzepte vermittelt, müssen praktische Kenntnisse in modernen Technologien oft selbst erworben oder durch praxisorientierte Ausbildungsformate ergänzt werden.
Die Zukunft der Softwareentwicklung wird höchstwahrscheinlich noch komplexer werden, doch die Grundprinzipien – sauberer Code, automatisierte Tests und eine gute Architektur – werden bestehen bleiben. Werkzeuge wie PHPUnit haben gezeigt, wie ein einzelnes Werkzeug eine ganze Branche verändern und die Qualität der Software nachhaltig verbessern kann.
Der Einfluss von KI
Du hast gerade deine Hochschulausbildung oder Ausbildung abgeschlossen und stehst vor einem Problem: Du hast zwar theoretisches Wissen, aber es fehlt dir an praktischer Erfahrung. Das ist völlig normal. Früher war dein Weg klar vorgezeichnet: Du bekamst einfache Aufgaben, brauchtest vielleicht eine Woche für etwas, wofür eine Expertin oder ein Experte einen halben Tag benötigt, sammeltest dabei wertvolle Erfahrungen und wurdest mit der Zeit selbst Expertin oder Experte.
Doch die künstliche Intelligenz verändert diese bewährte Lernkurve fundamental. Was früher als Sprungbrett für den Berufseinstieg diente, die zeitaufwendigen, aber lehrreichen Grundlagenaufgaben, wird heute zunehmend automatisiert. Aufgaben von Junior-Entwicklerinnen und Junior-Entwicklern werden zunehmend durch KI erledigt. Diese Entwicklung wirft eine existenzielle Frage auf: Woher sollen in Zukunft Erfahrung und Expertise kommen, wenn wir genau die Aufgaben automatisieren, durch die Einsteigerinnen und Einsteiger diese erwerben?
Martin Fowler legte 1999 mit seinem wegweisenden Buch "Refactoring: Improving the Design of Existing Code" den Grundstein für eine Revolution in der Softwareentwicklung. Seine systematische Katalogisierung von Code-Verbesserungen definierte einen kontrollierten Ansatz zur Verbesserung bestehender Software, ohne deren externes Verhalten zu verändern.
Die wahre Transformation kam jedoch erst mit der industriellen Umsetzung dieser Ideen. JetBrains veröffentlichte kurz darauf IntelliJ IDEA, eine der ersten integrierten Entwicklungsumgebungen mit umfassenden automatisierten Refactoring-Funktionen. Diese IDE machte Fowlers Konzepte für alle zugänglich: was zuvor manuell und fehleranfällig war, wurde zu einem einfachen Klick mit deterministischen, reproduzierbaren Ergebnissen.
Die heutige Generation von Werkzeugen für die Programmierung verfolgt einen grundlegend anderen Ansatz. KI-Assistenten zielen darauf ab, Code direkt zu generieren und den Menschen bei der Erstellung neuer Funktionen zu unterstützen. Diese Werkzeuge verwenden große Sprachmodelle, die auf Abermillionen von Code-Repositories trainiert wurden, um kontextbezogene Vorschläge zu liefern.
Diese KI-gestützten Ansätze bringen jedoch fundamentale Herausforderungen mit sich, die bei den klassischen Refactoring-Tools nicht existierten. KI-Assistenten sind von Natur aus nicht deterministisch: Der gleiche Prompt kann zu unterschiedlichen Code-Ausgaben führen. Diese Unvorhersagbarkeit steht im direkten Gegensatz zu den präzisen und reproduzierbaren Transformationen der Refactoring-Werkzeuge.
Während Refactoring-Operationen nachvollziehbare Änderungen mit klaren Transformationsregeln darstellen, entstehen durch KI-generierte Code-Blöcke oft umfangreiche Änderungen unbekannter Herkunft. Die Nachverfolgung von Änderungen und deren Begründung wird dadurch deutlich schwieriger.
In diesem Kontext gewinnt Test-Driven Development (TDD) eine neue, zentrale Bedeutung. Es fungiert als Stabilisator in einer zunehmend von KI-generiertem Code geprägten Welt. Tests spezifizieren das gewünschte Verhalten der Software. Sie werden von Menschen geschrieben und garantieren das deterministische Verhalten der Software.
Die unterschiedliche Bewertung dieser technologischen Entwicklungen lässt sich unter anderem durch generationsbedingte Akzeptanzmuster erklären. Douglas Adams hat dies einst treffend formuliert:
Anything that is in the world when you're born is normal. Anything invented between when you're fifteen and thirty-five is exciting and innovative. Anything invented after you're thirty-five is against the natural order of things.
Diese Beobachtung erklärt, warum erfahrene Entwicklerinnen und Entwickler KI-Assistenten möglicherweise skeptischer gegenüberstehen als ihre jüngeren Kollegen. Ihre Skepsis ist nicht unbegründet, sondern basiert auf der Erfahrung mit bewährten, deterministischen Werkzeugen sowie dem Verständnis für die Risiken nicht-deterministischer Systeme.
Künstliche Intelligenz wird die Softwareentwicklung vermutlich nachhaltig prägen und ist daher ein bleibender Faktor. Die Herausforderung besteht darin, einen Weg zu finden, auf dem beide Ansätze produktiv koexistieren können und ihre jeweiligen Stärken nutzen. KI-Assistenten können Menschen bei der schnellen Prototypenerstellung und der Automatisierung repetitiver Aufgaben unterstützen, während etablierte Praktiken wie TDD für die notwendige Stabilität und Qualitätssicherung sorgen.
Eine zu starke Abhängigkeit von KI-Assistenten kann jedoch zu einer schleichenden "Verdummung" von Entwicklerinnen und Entwicklern führen. Wer sich zu sehr auf automatisch generierten Code verlässt, verlernt grundlegende Programmierfähigkeiten. Diese Abhängigkeit ist gewollt: Je mehr Entwicklerinnen und Entwickler auf KI-Assistenten angewiesen sind, desto schwieriger wird es für sie, ohne diese Werkzeuge zu arbeiten.
Die derzeit niedrigen Preise für KI-Assistenten täuschen über die wahren langfristigen Kosten hinweg. Diese vermeintlich günstigen Konditionen folgen einer bewährten Marktstrategie: Erst werden niedrige Preise angeboten, um Abhängigkeiten zu schaffen. Sobald die Nutzerinnen und Nutzer nicht mehr ohne die Dienste arbeiten können, wollen oder dürfen, werden die Preise erhöht.
Der rasante Anstieg der KI-Nutzung führt zu einem dramatischen Anstieg des globalen Stromverbrauchs. Diese massive Energienachfrage verschärft die Klimakrise und erschwert die Erreichung der Klimaziele zusätzlich.
Der KI-Markt wird von einer Handvoll US-amerikanischer Unternehmen dominiert. Diese Abhängigkeit gefährdet Europas digitale Souveränität fundamental. Der US-amerikanische CLOUD Act ermöglicht es US-Behörden, auf Daten zuzugreifen, die von amerikanischen Technologieunternehmen gespeichert werden. Auch wenn diese außerhalb der USA liegen. Auch wenn diese Daten außerhalb der USA liegen. Dadurch wird Europa zu einer digitalen Kolonie der USA, ohne Kontrolle über die eigenen Daten und Infrastrukturen.
Die meisten großen KI-Modelle wurden zudem mit urheberrechtlich geschütztem Code trainiert, ohne dass die Rechteinhaber ihre Zustimmung gegeben haben. Die Free Software Foundation hat GitHub Copilot bereits als "unfair und nicht legal" bezeichnet und es gibt bereits mehrere Sammelklagen gegen KI-Anbieter. Diese rechtliche Unsicherheit zeigt, dass die Grundlagen der aktuellen KI-Entwicklung auf wackeligen Füßen stehen.
Die aktuell niedrigen Preise für KI-Assistenten sind eine Falle. Sie schaffen Abhängigkeiten, die später teuer bezahlt werden müssen: nicht nur finanziell, sondern auch mit dem Verlust der digitalen Souveränität. Europa darf nicht zulassen, dass eine Handvoll US-amerikanischer Konzerne die Zukunft der Künstlichen Intelligenz bestimmt.
Die ökologischen Kosten zentralisierter KI-Infrastrukturen, der schleichende Verlust von Entwicklerkompetenzen und die fragwürdigen rechtlichen Grundlagen der aktuellen KI-Entwicklung zeigen, dass dieses System nicht nachhaltig ist. Europa hat noch die Chance, eine Alternative aufzubauen. Doch mit jedem Tag, an dem die Abhängigkeit von US-Anbietern weiter wächst, schwindet diese Chance.
Dezentrale und lokale KI-Systeme sind nicht nur eine technische Alternative, sondern auch ein Gebot der politischen und wirtschaftlichen Vernunft. Nur so kann Europa seine digitale Zukunft selbst bestimmen und sich aus der Umklammerung der US-Technologiegiganten befreien, bevor diese ihre Marktmacht vollends ausnutzen.
Wenn du diesen doch recht langen Artikel zu Ende gelesen hast, könntest du fast denken: Das hier hätte ein Konferenzvortrag sein sollen. Dann hättest du statt vieler Zeilen Text wenigstens ein paar bunte Folien gesehen. Falls du jetzt neugierig geworden bist, keine Sorge: Genau diesen Vortrag gibt es schon.
