- Anfang der 1990er boten textbasierte IDEs selbst auf eingeschränkter Hardware bemerkenswerte Funktionen
- Die damals prägenden Borland-Turbo-Serien boten Syntax-Highlighting, Compiler-Integration, Debugging, Hilfe und mehr – also eine Umgebung, die modernen IDEs ebenbürtig war
- Unter Linux waren Vim und Emacs zwar anpassbar, hatten aber den Nachteil, schwer zu erlernen und für Einsteiger wenig intuitiv zu sein
- In letzter Zeit erleben TUIs (Text User Interfaces) und IDE-Funktionen durch neue Technologien wie LSP eine schrittweise Wiederbelebung, doch das integrierte Gesamtgefühl der 90er wird weiterhin nicht ganz erreicht
- Vorteile von TUI-IDEs sind Remote-Zugriff, geringer Ressourcenverbrauch und Open-Source-Freiheit; moderne IDEs fallen dagegen zunehmend durch Aufblähung durch zusätzliche Funktionen auf
Einleitung: Erinnerungen an textbasierte IDEs der frühen 1990er
- Ende der 1980er bis Anfang der 1990er hatte der Autor Spaß daran, alte Entwicklungsumgebungen mit DOSBox erneut zu erleben und mit der Gegenwart zu vergleichen
- Die damaligen textbasierten IDEs boten trotz Hardwarebeschränkungen erstaunlich viele Funktionen
- Danach verschwanden die meisten dieser Funktionen mit dem Aufstieg der Fensterbetriebssysteme für lange Zeit und tauchen erst in jüngerer Zeit teilweise wieder auf
Frühe Editoren und TUI-Umgebungen
- In den 1990ern nutzten die meisten DOS-Programme bildschirmfüllende Text User Interfaces (TUI), die textbasierte Fenster, Farben, Schatten und sogar Mausunterstützung boten
- Jedes Programm hatte zwar ein anderes Design, ließ sich aber dank ähnlicher Bedienkonzepte schnell erlernen
- MS-DOS bot ab Version 5 (1991) einen integrierten TUI-Editor, doch zum Kompilieren/Ausführen musste man den Editor beenden; beim erneuten Laden musste man die Arbeitsstelle wiederfinden, was unpraktisch war
- Es gab auch Werkzeuge auf Basis von TSRs (Terminate and Stay Resident) wie SideKick Plus (1984), die auf nicht multitaskingfähigen Betriebssystemen effizientes Bearbeiten und Bauen von Code ermöglichten
- Bereits Mitte bis Ende der 1980er erschienen frühe IDEs wie Turbo Pascal und QuickBASIC, die ein integriertes Entwicklungserlebnis boten
Die Borland-Turbo-Serie: der Höhepunkt integrierter IDEs
- Borland Turbo C++, Turbo Assembler und Turbo Pascal waren zwar jeweils auf eine bestimmte Sprache spezialisiert, boten aber ein bildschirmfüllendes TUI und starke Funktionen
- Wichtige Funktionen:
- Syntax-Highlighting für bessere Lesbarkeit des Codes
- Compiler-Integration sowie Warnungen/Diagnosen
- Projekt-/Build-System und Mehrfensterbetrieb
- Debugger (Breakpoints, Call Stack usw.)
- Integrierte Hilfe/Referenzhandbücher
- All diese Funktionen schufen auch ohne Internet in den frühen 1990ern eine in sich geschlossene und intuitive Umgebung
Vergleich mit der damaligen Linux-Umgebung
- Auch unter Linux dominierten textbasierte Werkzeuge, doch bildschirmfüllende TUIs waren dort selten
- Die in Büchern und Communities empfohlenen Vim und Emacs waren funktional erweiterbar, wirkten aus Sicht von Einsteigern jedoch wenig zugänglich und wenig intuitiv
- Bei Emacs waren zum Beispiel ein schmuckloses Fenster, eingeschränkte Farben, instabile Mausunterstützung und eine schwierige, ungewohnte Menüoberfläche problematisch
- IDEs wie Borland Turbo C++ ermöglichten es dagegen, auch ohne Vorwissen in wenigen Minuten ein „Hello World“-Programm zu erstellen und die Umgebung zu erkunden
Textbasierte IDEs heute
- Heute kommen RHIDE, Free Pascal und QB64 den TUI-IDEs von damals am nächsten
- RHIDE ist fast identisch zu Turbo C++, aber nur für DOS und wird nicht mehr weiterentwickelt
- Free Pascal unterstützt Unix-Umgebungen und bietet eine leistungsfähige integrierte Umgebung mit eingebautem Taschenrechner, ASCII-Tabelle usw.
- QB64 sieht wie eine TUI aus, ist aber tatsächlich eine GUI-Simulation und kann nicht im Terminal laufen
- Free Pascal und QB64 werden beide bis heute weiterentwickelt, sind aber wegen ihrer starken Bindung an ältere Sprachen nur begrenzt populär
Wirklich moderne Konsolen-IDEs
- Als aktuelle textbasierte integrierte Entwicklungsumgebungen sind Neovim, Doom Emacs und Helix bekannt
- Dank vielfältiger Plugins bieten sie Erfahrungen auf IDE-Niveau, erreichen aber nicht die sprachspezifische Integration und Intuitivität der Borland-Produktfamilie
- In letzter Zeit erhalten einfache TUI-Editoren wie GNU Nano wieder Aufmerksamkeit, doch ohne IDE-Funktionen erinnern sie eher an WordStar
- Letztlich erreichen heutige Konsoleneditoren entweder nicht das Erfahrungsniveau der 90er oder holen Funktionen von vor 30 Jahren nur mühsam wieder auf
Warum TUI-IDEs weiterhin gebraucht werden
- Selbst wenn die Remote-Funktionen von VSCode hervorragend sind, haben TUI-IDEs den Vorteil, dass sie sich nach einer SSH-Verbindung direkt auf der Remote-Maschine nutzen lassen
- Hinzu kommt, dass die Remote-Erweiterungen von VSCode nicht Open Source sind und auf manchen Betriebssystemen wie FreeBSD nicht funktionieren, was Einschränkungen mit sich bringt
- TUI-IDEs verbrauchen wenig Ressourcen und sind deshalb gerade in Remote-Umgebungen besonders nützlich
Aufblähung und das Phänomen „Bloat“
- Borland Turbo C++ konnte mitsamt aller Funktionen unter 9 MB installiert werden und lief mit 640 KB RAM
- Das heutige Doom Emacs benötigt mehr als 500 MB, moderne IDEs kommen teils auf mehrere GB – die Aufblähung ist damit zu einem ernsten Problem geworden
- VSCode ist mit 350 MB zwar recht leichtgewichtig, verbraucht als Electron-basierte Anwendung jedoch in der Praxis viele Systemressourcen
- Es gibt zwar Fortschritte bei Funktionen wie Refactoring, doch im Vergleich zu vor 30 Jahren ist die Innovation begrenzt
- KI-Codeassistenten sind eine neuere Veränderung, beruhen in der Praxis aber überwiegend auf Remote-Services
Fazit
- Der Autor nutzt je nach Situation verschiedene Entwicklungsumgebungen wie Doom Emacs, Vim, VSCode und IntelliJ
- Das integrierte Entwicklungserlebnis und die Effizienz der TUI-IDEs von vor 30 Jahren stehen in deutlichem Kontrast zur Aufblähung und Fragmentierung moderner IDEs
- Der Wert und das Potenzial textbasierter IDEs sind weiterhin relevant; wie sie sich weiterentwickeln und ob sie eine echte Wiedergeburt erleben, bleibt abzuwarten
1 Kommentare
Hacker-News-Kommentare
Ich war ziemlich schockiert darüber, dass Visual Basic im Bereich der grafischen Programmierung so gut war. Früher konnte man an einem Tag sehr schnell eine GUI-Anwendung mittlerer Komplexität entwickeln. C# WinForms kam dem noch am nächsten, aber die späteren Werkzeuge waren enttäuschend, weil sie die Perspektive einzelner Entwickler nicht berücksichtigten. Als neues starkes Entwicklungsparadigma schlage ich sprach- bzw. voicebasierte Entwicklung (SDD/VDD) vor. Es wäre schön, vom Schmerz des vielen Tippens befreit zu werden und mit KI so natürlich zu interagieren wie in einem Gespräch mit einem Kollegen. Damit das wirklich funktioniert, müssten die KI-Modelle allerdings deutlich schneller werden
Delphi war schon damals besser als Visual Basic und ist immer noch nutzbar. Lazarus gibt es ebenfalls weiterhin. Tatsächlich kommt C# WinForms der Delphi-Erfahrung am nächsten
Ich hatte den Eindruck, dass Qt Creator ein ähnliches Erlebnis wie VB6 bietet. Hast du das vielleicht schon einmal benutzt?
Ich finde, Emacs bietet all diese Eigenschaften immer noch. Was der Autor als „unkonventionell“ bezeichnet, liegt nur daran, dass er die Konventionen nicht kennt. Emacs ist vollständig selbst dokumentierend und interaktiv. Die beste textbasierte Oberfläche, die ich je benutzt habe, ist Magit innerhalb von Emacs (https://magit.vc/). Ich wünschte, mehr von Emacs wäre wie Magit. Selbst wenn ich eine andere IDE benutze, nutze ich Emacs als Git-Client
Emacs ist ein historisch tief verwurzeltes Werkzeug, das schon existierte, bevor Apple die Tastenkürzel cmd-z/x/c/v entwickelte. Damals waren in Programmer-Editoren eher WordStar-artige Kürzel verbreitet, etwa in den meisten Borland-Produkten. Es gab vor 30 bis 40 Jahren großartige IDEs, die heute kaum noch bekannt sind. Ein Beispiel ist Apple MPW (1986), ein GUI-Editor, bei dem jedes Fenster eine Unix-Shell sein konnte und sich Fenster sowie Bearbeitungsvorgänge per Shell-Skript steuern ließen; ein Quellcodeverwaltungssystem war ebenfalls eingebaut. Wenn man einen Befehl eingab und Option-Return drückte, erschien ein GUI-basiertes „Commando“-Fenster, in dem man alle Optionen auswählen konnte. Apple Dylan (1992–1995) war eine leistungsstarke IDE im Stil von Lisp/Smalltalk, und auch THINK Pascal und C (1986), Metrowerks Codewarrior (1993) sowie Macintosh Allegro Common Lisp waren innovativ. Es ist erstaunlich, dass so ausgefeilte IDEs in den 80ern bis frühen 90ern auf 8–40MHz-M68000-Systemen mit 2–32MB RAM möglich waren
Zu der Aussage, Emacs sei selbst dokumentierend und interaktiv: Als ich es zum ersten Mal benutzt habe, war nicht einmal leicht herauszufinden, wie man eine Datei speichert. Vielleicht besser als vi, aber für Einsteiger ohne Erklärung nicht ausreichend
Magit ist wirklich erstaunlich. Ich frage mich, wie man auf so ein Datenmodell kommt. Es fühlt sich an, als würde es etwas über das Datenmodell von Git hinaus implementieren. Im Gegensatz zur Zersplitterung des Git-Porcelain hat Magit eine systematische Struktur
IDEs im Turbo-Vision-Stil lassen einen die meisten Funktionen verstehen, wenn man nur ein paar Dinge wie Alt, Tab, Return, Esc und die Pfeiltasten kennt. Emacs hat diese einheitliche Bedienbarkeit nicht
Ich benutze Emacs seit über 25 Jahren und bin inzwischen völlig daran gewöhnt
Turbo Pascal war wirklich erstaunlich. Anfangs zögerte ich, weil es eine nicht standardkonforme Pascal-Implementierung war, aber konkurrierende Werkzeuge waren viel teurer und weniger leistungsfähig. Nachdem ich es selbst benutzt hatte, war ich völlig begeistert. Auf dem IBM PC erlebte ich eine schnelle und intuitive IDE. Unter den modernen IDEs ist Intellij seit über 25 Jahren den Konkurrenten weit überlegen. Microsoft-Produkte benutze ich seit Langem nicht mehr, daher habe ich keine Erfahrung mit VSCode. Eclipse war ebenfalls langsam, wenig intuitiv und voller Bugs. JetBrains ist eines der seltenen Unternehmen, das seiner Mission treu bleibt und seine Exzellenz bewahrt. Beeindruckend ist, wie kontinuierlich dort verschiedene Sprachen, Standards und Tools unterstützt werden und zugleich eine herausragende Qualität erhalten bleibt
Visual Studio unterstützt weiterhin WinForms und den grafischen Form-Designer und ist damit der Delphi-Erfahrung der späten 90er sehr ähnlich. Das liegt daran, dass WinForms VCL ganz offen nachgeahmt hat
Das Problem ist allerdings der Ressourcenverbrauch. Auf einem Cloud-Desktop kann ich neovim nicht nutzen und verwende deshalb ideavim, aber selbst mit 4 Kernen und 16GB RAM ruckelt es, sobald mehrere Projekte geöffnet sind. Möglicherweise spielt die Sicherheitssoftware meines Unternehmens mit hinein, aber VSCode ist nicht annähernd so belastend
Die Turbo-Pascal-IDE war ihrer Zeit voraus und auf CP/M, besonders Z-80, geradezu magisch gut. Sie war allem anderen ihrer Zeit überlegen
Der Artikel ist von 2023, also müsste man die Jahreszahl im Titel eigentlich auf 32 Jahre aktualisieren. Was mich bei heutigen TUIs am meisten stört, ist, dass asynchrone Frameworks Tasteneingaben oft einfach ignorieren. TUIs vor 2000 warteten Eingaben, selbst wenn das System noch nicht bereit war. Moderne „webbasierte“ TUI-Frameworks ignorieren Tastendrücke dagegen komplett, wenn man eine Taste drückt, bevor der Event-Listener registriert wurde. Abgesehen von solchen Problemen funktioniert TUI nach wie vor gut. Neovim bietet dank LSP und Plugins den wohl größten Funktionsumfang aller Zeiten. Es ist keine mausbasierte TUI, aber in Sachen Produktivität sehr stark
Auf echten Terminals in der DOS-Zeit gab es Eingabepuffer, und Leute, die die Oberfläche gut kannten, tippten oft mehrere Tasten im Voraus und waren damit schneller als die UI. Die Eingaben wurden im Puffer gesammelt und erschienen dann blitzschnell auf dem Bildschirm, nur um sofort wieder zu verschwinden. Auch mit modernen Frameworks kann man so etwas umsetzen, aber man muss dabei vorsichtig vorgehen
Ich hatte dieses Erlebnis schon 1984, also reicht der Zeitraum sogar bis vor 41 Jahren zurück. Frühe Projekte waren Mainstream, bis GUI-Produkte wie Visual Studio 1.0 oder NetBeans aufkamen. Das war noch vor vim (1991), aber gefühlt wollte man eher schwebende Fenster statt ncurses
Dieses Ignorieren von Tasteneingaben ist wahnsinnig frustrierend. Früher konnte man Computer mit schnellen Tastenkombinationen in irrwitzigem Tempo bedienen, heute fühlt es sich an, als würde man durch zähen Sirup laufen
Ich hatte kein klares Gefühl dafür, wann genau „vor 30 Jahren“ sein soll, und hoffte eigentlich auf einen GUI-Systembrowser für Smalltalk, bekam dann aber DOS-TUI und war etwas enttäuscht. Trotzdem kamen angenehme Erinnerungen an Turbo C/Pascal, MS C 4.0 und CodeView hoch. Diese Werkzeuge ließen sich sogar in 43- oder 50-Zeilen-Modi benutzen
Ich denke, dass eine zu starke Abhängigkeit von einer bestimmten IDE der eigenen Wettbewerbsfähigkeit und auch dem Code schaden kann. Wenn wir von Terminal-IDE sprechen, dann ist das GNU/Linux-Terminal selbst die beste App. Mit mehreren Terminalfenstern in einem Tiling-Window-Manager erreicht man maximale Produktivität. Modernes Scaling auf großen Displays ist auch ergonomisch für Entwickler hervorragend
Ich entwickle und benutze immer noch einen selbstgebauten textbasierten Editor bzw. eine IDE (https://github.com/alefore/edge). Die Schlussfolgerungen aus zehn Jahren Entwicklung habe ich kürzlich aufgeschrieben (https://github.com/alefore/weblog/blob/master/edge/README.md)
In der DOS-Blütezeit wurden Zeichen als Byte-Array verwaltet, und Attribute wie Hintergrund- oder Vordergrundfarbe in einem separaten Array. Wenn man an einer bestimmten Stelle ein „A“ schreiben wollte, musste man nur 0x41 an die passende Speicheradresse schreiben. Es gab zwar etwas wait state, aber das war immer noch viel schneller, als auf einem 9600-baud-Terminal per ANSI-Befehlen auszugeben. Emacs konnte auf langsamen seriellen Terminals oder im Terminalemulator einer Sun-Workstation benutzt werden, aber das erklärt auch, warum shellbasierte TUIs verschwunden sind
Auch wenn sich der Artikel auf textbasierte IDEs konzentriert, gilt das meiner Meinung nach genauso für traditionelle IDEs wie Visual Basic oder Delphi. Für Einsteiger wäre eine richtige Python-IDE wirklich nötig. Nicht textbasiert, sondern im Stil von Visual Basic, mit vollständiger Integration und einer Struktur, in der sich alles leicht entdecken lässt, und das ist wichtig. Ein GUI-Builder und ein Debugger sollten ebenfalls eingebaut sein. Der Code-Editor bräuchte nur Syntax-Highlighting, Autovervollständigung und einfache Code-Navigation. Zum Beispiel sollte man einen Button in ein Fenster ziehen und dann im GUI-Editor doppelklicken können, um direkt zum Handler-Code dieses Buttons zu springen. Vor einiger Zeit haben sich Leute schon einmal versammelt, um etwas in dieser Richtung zu diskutieren, aber die Debatte verlief im Sand, weil es große Meinungsverschiedenheiten über das zu nutzende GUI-Framework gab, etwa Pyside, Dear PyGui oder Web-Technologien. Wenn schon Free Pascal erwähnt wird, sollte man auch Lazarus (https://www.lazarus-ide.org/) nennen, den Delphi-Klon. Es ist wirklich hervorragend und wird aktiv weiterentwickelt. Allerdings wird Object Pascal heute nicht mehr oft verwendet und wirkt deshalb etwas veraltet
Ich stimme voll zu, dass Einsteiger für Python eine integrierte IDE im Stil von Visual Basic mit GUI-Builder und eingebautem Debugger brauchen. Es gab im Jahr 2000 mit Boa Constructor (https://boa-constructor.sourceforge.net/) bereits eine Python-IDE, aber sie wurde nie wirklich populär
Ich habe kürzlich auch ein Video aufgenommen, in dem ich unter Windows 3.11 mit VB3 eine kleine Toy-App baue, und dieser Tweet ging „viral“. Am Ende ist nicht TUI das Entscheidende, sondern die integrierte Nutzungserfahrung
Für mich ist Lazarus der Maßstab dafür, was eine echte IDE ist. Lazarus wurde mit Lazarus gebaut, und die Autoren benutzen ihr eigenes Produkt intensiv und liefern Beispiele sowie Tutorials. Auch zum Unterrichten von Kindern im Programmieren ist es hervorragend geeignet. Wie bei Microsoft Visual Studio sind dort Tagging, Suche, Hilfe, API-Dokumentation, Widget-Beispiele und Bibliotheken integriert. Andere IDEs haben diese Integration nicht, und Xcode nennt sich zwar IDE, ist aber im Vergleich zu Lazarus eher schwach. Ich bin so stur, dass ich seit sechs Monaten statt JS ein eigenes UI-Frontend-Framework in Go baue, und hoffe, irgendwann vielleicht auch eine IDE bauen zu können
Die IDEs von Borland waren eine echte Freude. Ich habe bis heute kein modernes Werkzeug gefunden, das ein ähnlich gutes Erlebnis bietet. Sicher, Nostalgie spielt vielleicht eine Rolle, aber es macht Spaß, sich sogar absichtlich einen Vorwand zu schaffen, Free Pascal zu benutzen, nur um diese Oberfläche wiederzusehen. Ich mag auch Pascal. Ich benutze manchmal Sam und Acme aus Plan 9, aber das sind keine IDEs, sondern Editoren. Ich bevorzuge Werkzeuge, die mich nicht stören und mir beim Denken helfen. Von den alten TUIs kann man viel lernen. Zum Beispiel war es völlig akzeptabel, ja geradezu heldenhaft, im File-Menü eine Shell zu öffnen, etwas auszuführen und dann wieder zurückzukehren. Und die Keybindings! Alte TUIs übernahmen oft das Tastenkürzelmuster von WordStar, und das sitzt mir so tief in den Fingern, dass sich Emacs anfühlt, als würde man mit Ofenhandschuhen tippen. Lange Zeit habe ich joe mit dem Alias jstar benutzt. Jetzt ist es wohl Zeit, eine Dr.-DOS-VM zu booten, Advent of Code zu probieren und absichtlich ineffizient in Erinnerungen zu schwelgen
„Professionelle“ Software aus der DOS-Zeit, etwa Emacs, war so konzipiert, dass der Benutzer vollständig innerhalb dieser Software lebte. Man verschmolz mit der Maschine und beherrschte die Tastenkürzel wie ein Organist. Ich erinnere mich an Mitarbeiter bei Fry’s Electronics, die TUI so schnell bedienten, dass sie ihre Arbeit erledigt hatten und schon Ausdrucke herauskamen, bevor der Bildschirm überhaupt sichtbar aktualisiert war
Mich würde interessieren, was genau WordStar-Bindings sind und was sie so gut macht. Ich interessiere mich dafür, die Geschichte solcher Muster und die Vorteile der verschiedenen Ansätze zu erforschen
Toller Beitrag, dem ich sehr zustimme. Ich entwickle in meiner Freizeit ebenfalls einen Code-Editor im TUI-Stil von Turbo Pascal und plane, später auch make und lldb zu integrieren
Ich mag viele Aspekte von Plan 9, aber mit Acmes mauszentrierter Oberfläche werde ich einfach nicht warm. Eine UI, die präzises Zielen mit der Maus verlangt, wäre bei langer Nutzung oder mit Einschränkungen sehr unbequem gewesen
Die Kombination aus djgpp und vi for dos 1991 war unschlagbar
Ich habe sowohl die Java-IDE Visix Vibe als auch Delphi verwendet, und beide Produkte haben meine Produktivität enorm gesteigert. Bei Kundenprojekten konnte ich die Entwicklung der UI, die Verknüpfung der Logik und die Vorbereitung der Auslieferung sehr leicht zeitlich abschätzen. Was ich bei beiden IDEs besonders vermisse, ist ihre Integration. Man konnte eine Datenbank anbinden, ein Formular erzeugen und sofort Eingaben und Validierung nutzen, und innerhalb weniger Tage ließ sich daraus eine UI entwickeln, die den Projektanforderungen entsprach. Heute muss man viel sorgfältiger planen und darüber nachdenken, ob UI, API und Backend wirklich sauber zusammenspielen. Ich habe das Gefühl, dass wir nicht nur Werkzeuge brauchen, die per KI UI-Code generieren, sondern weiterhin Werkzeuge, mit denen man Code visuell selbst zeichnet und Programme über die UI erstellt. Wenn jemand ein wirklich gutes WYSIWYG-Tool für JUCE herausbringt, könnte das goldene Zeitalter zurückkehren
In der DOS-Zeit gab es ein Byte-Array für Zeichen und ein Attribut-Array für Farben, und die Hardware zeichnete das direkt auf den Bildschirm. Man schrieb einfach einen Wert an eine Speicheradresse und er erschien sofort auf dem Display, was viel schneller war als langsame serielle Terminals oder ANSI-basierte Ausgaben. Wenn man Emacs auf dem Terminal einer Sun-Workstation benutzte, konnte das gar nicht anders als langsam sein, und deshalb verschwanden TUIs