Anders Hejlsbergs Lektionen: Softwarearchitektur, TypeScript, C#

Anders Hejlsbergs Prinzipien: Lehren für skalierbare und zukunftsfähige Softwarearchitektur

Anders Hejlsberg, der Architekt hinter ikonischen Programmiersprachen wie C# und TypeScript sowie der Schöpfer von Turbo Pascal und Delphi, prägt seit Jahrzehnten die Softwareentwicklung. Seine Karriere ist nicht nur vom Bau erfolgreicher Produkte geprägt, sondern auch von einer kontinuierlichen Reflexion über die Prinzipien, die es Systemen ermöglichen, den Herausforderungen der Zeit standzuhalten und zu skalieren. Eine tiefgehende Analyse seiner Arbeit offenbart universelle Muster, die auf die Gestaltung jedes komplexen Systems anwendbar sind, das langfristig bestehen und sich weiterentwickeln soll. Diese Lehren, die durch die Entwicklung entscheidender Werkzeuge für Millionen von Entwicklern entstanden sind, bleiben in einer sich ständig wandelnden Technologielandschaft relevant und umfassen Aspekte von der Geschwindigkeit des Feedbacks über die Rolle der künstlichen Intelligenz bis hin zur Bedeutung offener Zusammenarbeit.

1. Schnelles Feedback – Das Fundament der Produktivität

Anders Hejlsbergs frühe Erfahrungen waren von starken Einschränkungen geprägt. In einer Ära von Computern mit 64 KB Arbeitsspeicher gab es keinen Platz für Abstraktionen, die sich nicht selbst rechtfertigten. Er erinnert sich, dass ein Entwickler unter solchen Bedingungen „alles im Kopf behalten“ konnte und die Hauptanforderung die sofortige Ausführung des Codes nach dem Schreiben war.

„Wenn man Code eingab, wollte man ihn sofort ausführen“, — Anders Hejlsberg.

Google AdInline article slot

Der Einfluss von Turbo Pascal lag weniger in der Sprache Pascal selbst, als vielmehr in der radikalen Verkürzung des Feedback-Zyklus: Bearbeiten, Kompilieren, Ausführen, Debuggen, Wiederholen – alles ohne Festplattenzugriff und lange Wartezeiten. Dieser Ansatz sparte Entwicklern Zeit und Aufmerksamkeit und ermöglichte ihnen, effizienter zu arbeiten.

Dieselbe Idee, wenn auch in anderer Form, fand Jahrzehnte später in TypeScript ihre Verwirklichung. Die Sprache selbst ist nur ein Teil ihres Wertes. Ein erheblicher Teil der Vorteile von TypeScript liegt in seinen leistungsstarken Tools: inkrementelle Typüberprüfung, schnelle Teilergebnisse und Sprachdienste, die selbst bei sehr großen Codebasen sofort reagieren.

Die praktische Schlussfolgerung hier ist entscheidend: Entwickler können dieses Prinzip direkt bei der Werkzeugwahl anwenden. Schnelles Feedback verändert das Verhalten grundlegend. Wenn Fehler schnell sichtbar werden, sind Entwickler experimentierfreudiger, sicherer beim Refactoring und finden Probleme näher an ihrem Entstehungszeitpunkt. Umgekehrt, wenn Feedback langsam ist, sind Teams gezwungen, dies mit komplexen Konventionen, Workarounds und umständlichen Prozessen zu kompensieren. Ob bei der Wahl einer Sprache, eines Frameworks oder interner Tools – die Geschwindigkeit des Feedbacks ist entscheidend. Tools, die den Abstand zwischen dem Schreiben von Code und dem Verständnis seiner Auswirkungen verkürzen, schaffen Vertrauen. Solche, die Verzögerungen verursachen, auch wenn sie leistungsstark sind, bleiben oft auf der Strecke.

2. Software skalieren bedeutet, persönliche Vorlieben loszulassen

Als Hejlsberg von der Einzelarbeit zur Teamleitung wechselte, insbesondere während der Delphi-Ära, war der schwierigste Aspekt keine technische Veränderung, sondern die Notwendigkeit, persönliche Vorlieben aufzugeben. Er erkannte, dass man in der Teamentwicklung „akzeptieren muss, dass Dinge nicht so gemacht werden, wie man es selbst bevorzugen würde. Es zu korrigieren, ändert immer noch nichts am Verhalten.“

Dieser Ansatz geht weit über die Sprachentwicklung hinaus. Jedes System, das teamübergreifend skalieren muss, erfordert eine Verlagerung von individuellen Vorlieben zu gemeinsamen Standards. Das Ziel ist nicht länger „der Code, den man selbst schreiben würde“, sondern „Code, den viele verstehen, warten und weiterentwickeln können.“

C# entstand nicht als ideales „Tabula Rasa“-Konzept, sondern als Ergebnis widersprüchlicher Anforderungen. Visual Basic-Entwickler benötigten Einfachheit, C++-Entwickler benötigten Leistung, und Windows verlangte Pragmatismus. Das Ergebnis war kein theoretisch perfektes System, sondern eine Sprache, die Menschen effektiv nutzen konnten. Programmiersprachen sind nicht erfolgreich, weil sie perfekt entworfen sind, sondern weil sie die tatsächliche Arbeitsweise von Teams berücksichtigen und ihnen eine effektive Zusammenarbeit ermöglichen.

3. Warum TypeScript JavaScript erweiterte, anstatt es zu ersetzen

TypeScript entstand, weil JavaScript eine Skalierung erreichte, die nur wenige Sprachen je erreichen konnten. Als Browser zu einer echten plattformübergreifenden Laufzeitumgebung wurden, begannen Teams, Anwendungen zu entwickeln, die weit über das Niveau hinausgingen, das durch dynamische Typisierung effektiv unterstützt wurde. Frühe Versuche, dies zu beheben, waren oft recht radikal: Einige Teams kompilierten andere Sprachen nach JavaScript, um Zugang zu statischen Analyse- und Refactoring-Tools zu erhalten.

Dieser Ansatz gefiel Hejlsberg nie. Entwicklern zu sagen, sie sollten ein Ökosystem aufgeben, in das sie bereits tief investiert waren, war unrealistisch. Die Schaffung einer völlig neuen Sprache im Jahr 2012 hätte nicht nur einen Compiler erfordert, sondern jahrelange Investitionen in Editoren, Debugger, Refactoring-Tools und, am wichtigsten, die Akzeptanz durch die Community.

Stattdessen wählte TypeScript einen anderen Weg – es erweiterte JavaScript, übernahm dessen Schwächen, vereinfachte aber gleichzeitig die Entwicklung großer Projekte erheblich. Dies war keine ideologische, sondern eine rein praktische Entscheidung. TypeScript war erfolgreich, weil es innerhalb der Einschränkungen funktionierte, mit denen Entwickler bereits konfrontiert waren, anstatt sie zu zwingen, bestehende Tools, Bibliotheken und mentale Modelle aufzugeben.

Letztendlich ist die Hauptlektion die Notwendigkeit von Kompromissen. Verbesserungen, die bestehende Workflows berücksichtigen, verbreiten sich leichter, während Erweiterungen, die einen vollständigen Ersatz erfordern, selten Akzeptanz finden. In der Praxis wird signifikanter Fortschritt oft durch die Weiterentwicklung bestehender Systeme erzielt, auf die man bereits angewiesen ist, anstatt zu versuchen, bei Null anzufangen.

Offenheit und Anpassung an Veränderungen

4. Transparenz ist der Schlüssel zum Open-Source-Erfolg

TypeScript war kein sofortiger Erfolg. Frühe Versionen waren zwar formal Open Source, die Entwicklung erfolgte jedoch größtenteils hinter verschlossenen Türen. Dies änderte sich 2014, als das Projekt auf GitHub umzog und der Entwicklungsprozess vollständig offen wurde. Feature-Vorschläge kamen über Pull Requests, Kompromisse wurden öffentlich diskutiert und Aufgabenprioritäten basierten auf dem Feedback der Community.

Diese Umstellung machte den Entscheidungsprozess transparent. Entwickler konnten nicht nur sehen, was veröffentlicht wurde, sondern auch, warum bestimmte Entscheidungen getroffen und andere nicht berücksichtigt wurden. Für das Team änderte sich dadurch auch die Herangehensweise an die Priorisierung der Arbeit. Anstatt zu raten, was am wichtigsten war, konnten sie direkt beobachten, welche Probleme den Entwicklern am Herzen lagen.

Effektive Open-Source-Projekte tun mehr als nur Code zu veröffentlichen. Sie machen den Entscheidungsprozess sichtbar – damit Mitwirkende Prioritäten und Kompromisse verstehen, was letztendlich Vertrauen aufbaut und eine aktivere Beteiligung der Community fördert.

5. Der Abschied von JavaScript als Implementierungssprache war notwendig

Viele Jahre lang war der TypeScript-Compiler selbst-hostend: in TypeScript geschrieben und als JavaScript ausgeführt. Dies bot leistungsstarke In-Browser-Tools und vereinfachte das Experimentieren. Mit der Zeit zeigten sich jedoch Einschränkungen. JavaScript ist Single-Threaded, es fehlt die Shared-Memory-Parallelität, und sein Objektmodell ist, obwohl flexibel, ressourcenintensiv. Als TypeScript-Projekte wuchsen, ließ der Compiler einen Großteil der verfügbaren Rechenressourcen ungenutzt.

Das Team erreichte einen Punkt, an dem weitere Optimierungen nicht mehr ausreichten. Sie benötigten ein anderes Ausführungsmodell. Die kontroverse Entscheidung war, den Compiler nach Go zu portieren. Dies war keine komplette Neuentwicklung. Das Ziel war semantische Treue. Der neue Compiler musste sich genau wie der alte verhalten, einschließlich Eigenheiten und Grenzfälle. Rust hätte trotz seiner Popularität aufgrund von Ownership-Einschränkungen und der weit verbreiteten Verwendung zyklischer Datenstrukturen eine erhebliche Neugestaltung der Architektur erfordert. Go's Garbage Collection und die strukturelle Ähnlichkeit zu TypeScript ermöglichten es, das Verhalten beizubehalten und gleichzeitig Leistung und Parallelität zu verbessern.

Das Ergebnis war ein signifikanter Leistungsschub, sowohl bei der nativen Ausführung als auch bei der Parallelität. Wichtiger noch, die Community musste das Verhalten des Compilers nicht neu lernen. Manchmal ist die verantwortungsvollste Wahl nicht die ambitionierteste, sondern diejenige, die das Verhalten bewahrt, Störungen minimiert und eine harte Einschränkung beseitigt, die durch inkrementelle Optimierung nicht zu überwinden ist.

Die Zukunft der Entwicklung und die Rolle der Zusammenarbeit

6. Im Zeitalter der KI zählen Einschränkungen mehr als Generierung

Anders Hejlsberg steht der Idee von Programmiersprachen, die primär für KI entwickelt wurden, skeptisch gegenüber. Er merkt an, dass große Sprachmodelle am besten mit Sprachen funktionieren, denen sie bereits häufig begegnet sind, was natürlich massive Ökosysteme wie JavaScript, Python und TypeScript begünstigt.

KI verändert jedoch das Spiel, wenn es um Tools geht. Das traditionelle IDE-Modell ging davon aus, dass der Entwickler Code schreibt und Tools zur Unterstützung des Prozesses verwendet. Zunehmend kehrt sich diese Beziehung um: KI-Systeme generieren Code, und Entwickler überprüfen und korrigieren ihn. Deterministische Tools wie Typ-Checker und Refactoring-Engines dienen als Leitplanken, die subtile Fehler verhindern. Der Wert solcher Tools liegt in Präzision und Einschränkungen: Sie müssen genaue semantische Informationen liefern, damit KI-Systeme sinnvolle Fragen stellen und zuverlässige Antworten erhalten können.

Das Risiko besteht nicht darin, dass KI-Systeme schlechten Code generieren, sondern dass sie plausiblen Code generieren, der nicht alle Nuancen der Codebasis eines Projekts berücksichtigt. Für Entwickler verschiebt sich dadurch der Fokus. Letztendlich sind die wertvollsten Tools in einem KI-gestützten Workflow diejenigen, die ihn richtig einschränken. Starke Typsysteme, robuste Refactoring-Tools und präzise semantische Modelle werden zu unverzichtbaren Ermöglichern. Sie bieten die Struktur, die es ermöglicht, die Ausgaben von KI-Systemen effektiv zu überprüfen, zu validieren und zu korrigieren, anstatt ihnen blind zu vertrauen.

7. Die entscheidende Bedeutung offener Zusammenarbeit

Trotz der Herausforderungen bei Finanzierung und Wartung bleibt Hejlsberg optimistisch, was die offene Zusammenarbeit angeht. Ein Hauptgrund ist das institutionelle Gedächtnis. Jahre der Diskussionen, getroffene Entscheidungen und erzielte Kompromisse bleiben durchsuchbar und einsehbar.

Diese Geschichte geht nicht in privaten E-Mail-Ketten oder internen Systemen verloren. Sie bleibt für jeden zugänglich, der verstehen möchte, wie und warum sich das System entwickelt hat. „Wir haben 12 Jahre Geschichte in unserem Projekt dokumentiert“, erklärt er. „Wenn sich jemand daran erinnert, dass eine Diskussion stattgefunden hat, können wir sie normalerweise finden. Kontext verschwindet nicht in E-Mails oder privaten Systemen.“ Diese Zugänglichkeit verändert, wie sich Systeme entwickeln. Design-Diskussionen, verworfene Ideen und Kompromisse bleiben lange nach einzelnen Entscheidungen verfügbar. Für Entwickler, die später einem Projekt beitreten, ist dieser gemeinsame Kontext oft so wertvoll wie der Code selbst.

Wichtige Erkenntnisse

• Schnelles Feedback ist ein entscheidender Faktor für Produktivität und Entwicklungsqualität, da es Experimente und eine schnelle Problemidentifikation ermöglicht.
• Skalierung erfordert das Loslassen persönlicher Vorlieben zugunsten gemeinsamer, verständlicher Regeln und pragmatischer Lösungen, die den tatsächlichen Teambedürfnissen entsprechen.
• Evolutionäre Entwicklung (Erweiterung bestehender Systeme, wie TypeScript für JavaScript) ist oft effektiver als ein revolutionärer Ersatz, da sie bestehende Workflows und Ökosysteme respektiert.
• Prozessoffenheit in Open-Source-Projekten schafft Vertrauen, gewährleistet Transparenz bei der Entscheidungsfindung und bewahrt wertvolles institutionelles Gedächtnis.
• Bei der Integration von KI in die Entwicklung sollte der Fokus auf Tools liegen, die Präzision und Einschränkungen bieten (z. B. starke Typsysteme), um als „Leitplanken“ für generierten Code zu dienen.

Fazit: Ein über Jahrzehnte wiederholtes Modell

Über vier Jahrzehnte der Entwicklung von Programmiersprachen hinweg tauchen immer wieder dieselben Themen auf:

• Schnelles Feedback ist wichtiger als architektonische Eleganz.
• Systeme müssen unvollkommenen Code berücksichtigen, der von vielen Personen geschrieben wurde.
• Verhaltenskompatibilität ist oft entscheidender als architektonische Reinheit und theoretische Ideale.
• Sichtbare Kompromisse und Prozesstransparenz stärken das Vertrauen der Community.

Dies sind keine Nebensächlichkeiten. Dies sind grundlegende Entscheidungen, die bestimmen, ob ein Tool sich anpassen kann, wenn seine Nutzerbasis wächst, und den Prüfungen der realen Welt standhält. Darüber hinaus dienen sie als Grundlage für Innovationen und stellen sicher, dass neue Ideen eingeführt werden können, ohne das zu zerstören, was bereits funktioniert. Für diejenigen, die Tools entwickeln, die Bestand haben sollen, sind diese grundlegenden Prinzipien genauso wichtig wie revolutionäre Funktionen. Und das ist vielleicht Anders Hejlsbergs wichtigste Lektion.

— Editorial Team