- Au début des années 1990, les IDE en mode texte offraient des fonctionnalités remarquables malgré un matériel limité
- La célèbre série Borland Turbo, référence de l’époque, proposait coloration syntaxique, compilateur intégré, débogage, aide et un environnement comparable aux IDE modernes
- Sous Linux, Vim et Emacs étaient personnalisables, mais difficiles à apprendre et peu intuitifs pour les débutants
- Aujourd’hui, les TUI (interfaces texte) et certaines fonctions d’IDE reviennent progressivement grâce à de nouvelles technologies comme le LSP, mais sans retrouver encore le niveau d’intégration des années 1990
- Les atouts des IDE TUI sont l’accès à distance, une faible consommation de ressources et la liberté de l’open source ; à l’inverse, les IDE modernes souffrent d’un phénomène de bloat de plus en plus marqué
Introduction : le souvenir des IDE en mode texte du début des années 1990
- Entre la fin des années 1980 et le début des années 1990, l’auteur a repris en main d’anciens environnements de développement avec DOSBox et a pris plaisir à les comparer au présent
- Malgré les contraintes matérielles, les IDE en mode texte de l’époque disposaient déjà de nombreuses fonctionnalités
- Par la suite, la plupart de ces fonctions ont disparu pendant longtemps avec l’essor des systèmes d’exploitation à fenêtres, avant que certaines ne réapparaissent récemment
Les premiers éditeurs et l’environnement TUI
- Dans les années 1990, la plupart des programmes DOS utilisaient une interface plein écran en mode texte (TUI, Text User Interface) avec fenêtres textuelles, couleurs, ombres et même la souris
- Chaque programme avait son propre design, mais leur mode de fonctionnement similaire permettait une prise en main rapide
- À partir de la version 5 (1991), MS-DOS fournissait un éditeur TUI intégré, mais il fallait quitter l’éditeur pour compiler ou exécuter, puis retrouver ensuite sa position dans le fichier, ce qui était peu pratique
- Il existait aussi des outils fondés sur des TSR (programmes résidents) comme SideKick Plus (1984), qui permettaient une édition de code et des builds efficaces sur des OS sans multitâche
- Dès le milieu et la fin des années 1980, des premiers IDE comme Turbo Pascal ou QuickBASIC offraient déjà une expérience de développement intégrée
La série Borland Turbo : l’apogée de l’IDE intégré
- Borland Turbo C++, Turbo Assembler, Turbo Pascal, etc. étaient dédiés à un langage précis, tout en offrant une TUI plein écran et de puissantes fonctionnalités
- Fonctions principales :
- Coloration syntaxique pour améliorer la lisibilité du code
- Intégration du compilateur avec avertissements et diagnostics
- Système de projet/build et gestion multifenêtre
- Débogueur (points d’arrêt, pile d’appels, etc.)
- Aide intégrée / manuel de référence
- L’ensemble fournissait un environnement autonome et intuitif, sans Internet au début des années 1990
Comparaison avec l’environnement Linux de l’époque
- Linux utilisait lui aussi majoritairement des outils en mode texte, mais les TUI plein écran y étaient rares
- Vim et Emacs, recommandés dans les livres et les communautés, pouvaient être étendus fonctionnellement, mais paraissaient peu accueillants et peu intuitifs pour les débutants
- Par exemple, Emacs souffrait d’une fenêtre austère, de couleurs limitées, d’une prise en charge instable de la souris et d’une interface de menus difficile et inhabituelle
- À l’inverse, des IDE comme Borland Turbo C++ permettaient de créer un programme « Hello World » et d’explorer l’environnement en quelques minutes, même sans connaissance préalable
Les IDE en mode texte d’aujourd’hui
- Parmi les environnements les plus proches des anciens IDE TUI, on trouve aujourd’hui RHIDE, Free Pascal et QB64
- RHIDE est presque identique à Turbo C++, mais il est réservé à DOS et n’est plus développé
- Free Pascal prend en charge les environnements Unix et offre un environnement intégré puissant avec calculatrice intégrée, table ASCII, etc.
- QB64 ressemble à une TUI, mais il s’agit en réalité d’une simulation GUI et il ne peut pas s’exécuter dans un terminal
- Free Pascal et QB64 sont encore développés récemment, mais leur exposition à des langages vieillissants limite leur popularité auprès du grand public
Les véritables IDE console modernes
- Parmi les environnements de développement intégrés en mode texte les plus connus aujourd’hui figurent Neovim, Doom Emacs et Helix
- Grâce à de nombreux plugins, ils offrent une expérience proche d’un IDE, mais restent moins intégrés et moins intuitifs, par langage, que la gamme Borland
- Des outils récents comme GNU Nano sont aussi remis en avant comme éditeurs TUI simples, mais sans fonctions d’IDE, avec une sensation proche de WordStar
- En fin de compte, les éditeurs console actuels n’atteignent pas encore le niveau d’expérience des années 1990, ou ne font que retrouver à grand-peine des fonctions disponibles il y a 30 ans
Pourquoi les IDE TUI restent nécessaires
- Même si les fonctions distantes de VSCode sont excellentes, un IDE TUI garde l’avantage de pouvoir être utilisé immédiatement après une connexion SSH à une machine distante
- En outre, l’extension distante de VSCode n’est pas open source et ne fonctionne pas sur certains OS comme FreeBSD, ce qui impose des limites
- Les IDE TUI consomment peu de ressources et sont encore plus utiles dans les environnements distants
L’alourdissement et le phénomène de « bloat »
- Borland Turbo C++ intégrait toutes ses fonctions dans une installation de moins de 9 Mo et pouvait fonctionner avec 640 Ko de RAM
- Doom Emacs actuel dépasse les 500 Mo, et les IDE modernes atteignent plusieurs Go, ce qui rend le bloat particulièrement frappant
- VSCode, avec ses 350 Mo, reste relativement léger, mais sa base Electron entraîne en pratique une forte consommation de ressources système
- Il existe bien des avancées, comme certaines fonctionnalités ou le refactoring, mais l’innovation reste limitée par rapport à il y a 30 ans
- L’assistance au code par IA constitue un changement récent, mais repose en réalité majoritairement sur des services distants
Conclusion
- L’auteur utilise selon les situations différents environnements de développement, dont Doom Emacs, Vim, VSCode et IntelliJ
- L’expérience de développement intégrée et l’efficacité offertes par les IDE TUI d’il y a 30 ans contrastent nettement avec le bloat et la fragmentation des IDE modernes
- La valeur et le potentiel des IDE en mode texte restent bien réels, et il faudra voir comment ils évolueront et s’ils connaîtront un véritable renouveau
1 commentaires
Avis Hacker News
J’ai été très surpris de constater à quel point Visual Basic était excellent pour la programmation graphique. À l’époque, on pouvait développer très rapidement une application GUI de niveau intermédiaire en une journée. C# WinForms est ce qui s’en est le plus approché, mais c’est dommage que tous les outils suivants n’aient pas vraiment pris en compte le point de vue du développeur individuel. Je propose un nouveau paradigme de développement puissant, basé sur la voix/la parole (SDD/VDD). Cela permettrait de se libérer de la douleur de tant de saisie, et j’aimerais que l’interaction avec l’IA devienne aussi naturelle qu’une conversation avec un collègue. Mais pour que cela se concrétise vraiment, il faudra que les modèles d’IA deviennent bien plus rapides
Delphi était déjà supérieur à Visual Basic à l’époque, et il reste utilisable aujourd’hui. Lazarus existe toujours aussi. En pratique, C# WinForms est ce qui se rapproche le plus de l’expérience Delphi
J’avais l’impression que Qt Creator offrait une expérience similaire à VB6. Je me demande si vous l’avez déjà utilisé
Je pense qu’Emacs offre toujours toutes ces caractéristiques. Ce que l’auteur qualifie de « non traditionnel » vient surtout du fait qu’il n’est pas familier avec ces conventions. Emacs est entièrement auto-documenté et interactif. La meilleure interface en mode texte que j’ai jamais utilisée reste Magit dans Emacs (https://magit.vc/). J’aimerais que davantage d’éléments d’Emacs ressemblent à Magit. Même quand je change d’IDE, j’utilise Emacs comme client git
Emacs est un outil historique, qui existait déjà avant qu’Apple ne développe les raccourcis cmd-z/x/c/v. À l’époque, les raccourcis des éditeurs pour programmeurs relevaient surtout de la famille Wordstar (par exemple dans la plupart des produits Borland). Il existait autrefois d’excellents IDE, assez peu connus aujourd’hui, d’il y a 30 à 40 ans. Par exemple, Apple MPW (1986) était un éditeur GUI dont toutes les fenêtres étaient des shells Unix, et où l’on pouvait contrôler les fenêtres et les opérations d’édition via des scripts shell, avec en plus un système de gestion de code source intégré. On tapait une commande, puis option-Return, et une fenêtre GUI « Commando » apparaissait pour permettre de sélectionner toutes les options. Apple Dylan (1992-1995) était un IDE puissant dans l’esprit Lisp/Smalltalk, et THINK Pascal et C (1986), Metrowerks Codewarrior (1993), ainsi que Macintosh Allegro Common Lisp, étaient eux aussi innovants. Il est étonnant de voir à quel point ces IDE étaient sophistiqués sur des machines M68000 à 8~40MHz avec 2~32MB de RAM dans les années 80 et au début des années 90
Concernant l’idée qu’Emacs est auto-documenté et interactif, en pratique, lors de ma première prise en main, il n’était même pas évident de comprendre comment enregistrer un document. C’est sans doute mieux que vi, mais ce n’est pas assez accessible pour qu’un débutant l’utilise sans explication
Magit est vraiment impressionnant. Je me demande comment ils ont eu l’idée d’un tel modèle de données. J’ai l’impression qu’il va au-delà du modèle de données de git lui-même. Comparé au désordre du porcelain git, Magit a une structure cohérente
Les IDE dans le style Turbo-Vision permettent de comprendre la plupart des fonctions avec seulement quelques touches comme Alt, Tab, Return, Esc et les flèches, alors qu’Emacs n’a pas cette uniformité d’interaction
J’utilise Emacs depuis plus de 25 ans, donc maintenant j’y suis complètement habitué
Turbo Pascal était vraiment incroyable. Au début, j’hésitais à l’utiliser parce que c’était une implémentation non standard de Pascal, mais les outils concurrents étaient bien trop chers et moins puissants. Une fois essayé, j’en suis devenu totalement fan. J’ai découvert sur IBM PC un IDE rapide et intuitif. Parmi les IDE modernes, Intellij surpasse largement ses concurrents depuis plus de 25 ans. Je n’utilise plus les produits Microsoft depuis longtemps, donc je n’ai pas d’expérience avec VSCode. Eclipse était lent, peu intuitif et bourré de bugs. JetBrains est une entreprise rare qui reste fidèle à sa mission et maintient un haut niveau d’excellence. C’est impressionnant de les voir prendre en charge en continu autant de langages, de standards et d’outils tout en conservant une qualité remarquable
Visual Studio prend toujours en charge WinForms et le concepteur graphique de formulaires, ce qui est très proche de l’expérience Delphi de la fin des années 90. C’est parce que WinForms copie ouvertement VCL
En revanche, la consommation de ressources est un vrai problème. Comme je ne peux pas utiliser neovim sur un desktop cloud, j’ai fini par utiliser ideavim, mais même avec 4 cœurs et 16GB de RAM, ça saccade dès que j’ouvre plusieurs projets. Le logiciel de sécurité de l’entreprise y contribue peut-être, mais VSCode ne souffre pas autant
L’IDE de Turbo Pascal était en avance sur son temps, et il était formidable presque comme par magie même sur CP/M (surtout Z-80). C’était meilleur que tout le reste à l’époque
L’article date de 2023, donc le titre devrait plutôt être mis à jour à 32 ans. Ce qui me manque le plus dans les TUI aujourd’hui, c’est que les frameworks asynchrones ignorent parfois les frappes clavier. Les TUI d’avant 2000 mettaient les touches en attente même quand le système n’était pas prêt. À l’inverse, dans les frameworks TUI modernes « basés sur le web », si on appuie sur une touche avant que l’event listener soit enregistré, elle est tout simplement perdue. En dehors de ce problème, les TUI fonctionnent toujours très bien. Neovim offre les meilleures fonctionnalités de toute son histoire grâce au LSP et aux plugins. Ce n’est pas un TUI orienté souris, mais en matière de productivité, c’est excellent
À l’époque du DOS, sur de vrais terminaux, il y avait un buffer de saisie, et les gens habitués à l’interface tapaient plusieurs touches à l’avance, prenant de vitesse l’UI. Les entrées s’accumulaient dans le buffer, puis apparaissaient et disparaissaient à l’écran en un éclair. On peut encore implémenter cette structure avec des frameworks modernes, mais il faut le faire avec précaution
J’ai connu ce genre d’expérience dès 1984, donc on peut remonter jusqu’à 41 ans. Les premiers projets de ce type dominaient avant l’arrivée des produits GUI comme Visual Studio 1.0 ou NetBeans. C’était avant vim (1991), mais avec cette envie d’avoir des fenêtres flottantes plutôt que ncurses
Cette perte de frappes est d’une frustration absolue. Avant, on pouvait utiliser un ordinateur à une vitesse folle avec des combinaisons de raccourcis rapides, alors qu’aujourd’hui on a l’impression d’avancer dans de la mélasse
Je n’arrivais pas bien à situer ce que signifiait exactement « il y a 30 ans », et j’espérais voir apparaître le navigateur système GUI de Smalltalk, mais j’ai été déçu de voir un DOS TUI à la place. En revanche, ça m’a replongé avec plaisir dans les souvenirs de Turbo C/Pascal, MS C 4.0 et CodeView. On pouvait utiliser ces outils même en mode 43 lignes ou 50 lignes
Je pense qu’une dépendance excessive à un IDE précis peut nuire à sa compétitivité personnelle ou même à la qualité de son code. Si l’on parle d’IDE en terminal, alors le terminal GNU/Linux est la meilleure application qui soit. Utiliser plusieurs terminaux dans un gestionnaire de fenêtres tiling maximise la productivité. Le scaling moderne sur grand écran est aussi excellent du point de vue ergonomique pour les développeurs
Je continue à développer et utiliser un éditeur/IDE en mode texte que j’ai créé moi-même (https://github.com/alefore/edge). J’ai récemment écrit les conclusions de 10 ans de développement (https://github.com/alefore/weblog/blob/master/edge/README.md)
À l’apogée du DOS, on gérait les caractères comme un tableau d’octets et les attributs (fond, couleur de premier plan, etc.) dans un tableau séparé. Si l’on voulait écrire un « A » à un emplacement donné, il suffisait d’écrire 0x41 à l’adresse mémoire correspondante. Il y avait quelques wait states, mais c’était bien plus rapide que d’afficher via des commandes ANSI sur un terminal à 9600 baud. On pouvait utiliser Emacs sur un terminal série lent ou via l’émulateur de terminal d’une station Sun, mais c’est aussi ce qui explique la disparition des TUI basés sur le shell
Même si cet article se concentre sur les IDE en mode texte, je pense que cela vaut aussi pour les IDE traditionnels comme Visual Basic ou Delphi. À mon avis, les débutants ont vraiment besoin d’un IDE Python. Pas un outil en mode texte, mais quelque chose dans le style de Visual Basic, où tout est intégré et facile à découvrir (c’est important !). Ce serait encore mieux avec un constructeur GUI et un débogueur intégrés. Pour l’éditeur de code, la coloration syntaxique, l’autocomplétion et une navigation simple dans le code suffiraient. Par exemple, déposer un bouton dans une fenêtre puis double-cliquer dessus dans l’éditeur GUI pour aller directement au code du gestionnaire correspondant. Il y a quelque temps, des gens ont essayé de se réunir autour d’une idée similaire, mais la discussion s’est enlisée à cause des désaccords sur le framework GUI à utiliser (Pyside, Dear PyGui, basé sur le web, etc.). Puisqu’on parle de Free Pascal, il faut aussi mentionner Lazarus (https://www.lazarus-ide.org/), qui clone Delphi. C’est excellent et activement développé. En revanche, Object Pascal donne aujourd’hui une impression un peu datée, car il n’est plus beaucoup utilisé
Je suis tout à fait d’accord sur le besoin d’un IDE Python intégré pour débutants, dans le style Visual Basic, avec constructeur GUI et débogueur intégré. Il existait déjà un IDE Python appelé Boa Constructor (https://boa-constructor.sourceforge.net/) en 2000, mais il ne s’est pas imposé
J’ai récemment filmé le processus de création d’une petite appli sur Windows 3.11 avec VB3, et ce tweet est devenu « viral ». Au final, ce qui compte, ce n’est pas le TUI, mais l’expérience d’utilisation intégrée
Pour moi, Lazarus est le véritable étalon de l’IDE. Lazarus a été créé avec Lazarus, et son auteur utilise intensivement son propre produit tout en fournissant des exemples et des tutoriels. C’est aussi excellent pour enseigner la programmation aux enfants. Comme Microsoft Visual Studio, tout y est intégré : tagging, recherche, aide, documentation API, exemples de widgets, bibliothèques, etc. Les autres IDE n’ont pas ce niveau d’intégration, et même Xcode, qui se dit IDE, fait pâle figure en comparaison de Lazarus. Je suis tellement têtu que, depuis six mois, je développe moi-même un framework frontend UI en Go au lieu d’utiliser JS, alors j’espère qu’un jour je pourrai aussi créer un IDE
Les IDE de Borland étaient un vrai bonheur. Je n’ai toujours pas trouvé d’outil moderne qui procure une expérience comparable. Bien sûr, il y a peut-être un peu de nostalgie, mais même me trouver exprès une excuse pour utiliser Free Pascal et retrouver cette interface me fait plaisir. J’aime aussi Pascal. J’utilise parfois Sam et Acme de Plan 9, mais ce ne sont pas des IDE, plutôt des éditeurs. Je préfère les outils qui me laissent réfléchir sans me gêner. Il y a beaucoup à apprendre des anciens TUI. Par exemple, lancer un shell depuis le menu File, exécuter quelque chose, puis revenir, c’était tout à fait acceptable, voire héroïque. Et puis les keybindings ! Les anciens TUI reprenaient souvent les schémas de raccourcis de WordStar, tellement ancrés dans mes habitudes qu’Emacs me donne l’impression de taper avec des moufles de four. J’ai longtemps utilisé joe (alias jstar). Il est maintenant temps de démarrer une VM Dr. DOS, de faire quelques défis Advent of Code et de célébrer la nostalgie avec une inefficacité assumée
Les logiciels « professionnels » de l’époque DOS (Emacs, etc.) étaient conçus pour que l’utilisateur vive entièrement dans ce logiciel. On faisait corps avec la machine et on maniait les raccourcis comme un organiste. Je me souviens des employés de Fry’s Electronics manipulant les TUI si vite qu’ils avaient terminé leur tâche et que l’impression sortait avant même que l’écran ne s’affiche vraiment
Je suis curieux de savoir ce que sont les bindings WordStar et ce qu’ils ont de si intéressant. Je m’intéresse à l’histoire de ces schémas et aux avantages respectifs de chaque approche
Je partage totalement ce très bon commentaire. Moi aussi, je développe sur mon temps libre un éditeur de code TUI dans le style Turbo Pascal. Plus tard, j’aimerais y intégrer make et lldb
J’aime beaucoup plusieurs aspects de Plan 9, mais je n’ai jamais réussi à m’habituer à l’interface très orientée souris d’Acme. Une UI exigeant une précision de visée avec la souris devait être très inconfortable à long terme, ou pour des personnes en situation de handicap
La combinaison djgpp et vi for dos 1991 était la meilleure
J’ai utilisé à la fois un IDE Java appelé Visix Vibe et Delphi, et les deux m’ont énormément fait gagner en productivité. Je pouvais facilement prévoir les délais pour développer l’UI, raccorder la logique et préparer le déploiement chez le client. Ce qui me manque le plus, c’est surtout le niveau d’intégration de ces deux IDE. On pouvait connecter une base de données, générer un formulaire, puis saisir et valider immédiatement. En quelques jours, on faisait évoluer le projet vers une UI adaptée aux exigences du client. Aujourd’hui, il faut beaucoup plus de conception et de réflexion pour s’assurer que l’UI, l’API et le backend s’imbriquent correctement. J’ai l’impression qu’au-delà de l’IA qui génère du code d’UI, il nous faut encore des outils permettant de dessiner visuellement le code et de construire le programme à travers l’interface. Si quelqu’un sortait un vrai bon outil WYSIWYG pour JUCE, je pense qu’un nouvel âge d’or pourrait revenir
À l’époque du DOS, on avait un tableau d’octets pour représenter les caractères et un autre pour les attributs de couleur, et le matériel se chargeait directement de l’affichage. Il suffisait d’écrire une valeur à une adresse mémoire pour qu’elle apparaisse aussitôt à l’écran, ce qui était bien plus rapide qu’un terminal série lent ou qu’un affichage basé sur des commandes ANSI. Si Emacs paraissait lent sur les terminaux de stations Sun, c’était inévitable, et c’est aussi pour cela que les TUI ont disparu