- A comienzos de los años 90, los IDE basados en texto ofrecían funciones sobresalientes incluso en hardware limitado
- La emblemática serie Borland Turbo, uno de los IDE más representativos de la época, ofrecía un entorno comparable al de los IDE modernos, con resaltado de sintaxis, integración con el compilador, depuración y ayuda
- En Linux, Vim y Emacs permitían personalización, pero tenían la limitación de ser difíciles de aprender y poco intuitivos para principiantes
- Últimamente, los TUI (interfaces de texto) y las funciones de IDE están resurgiendo poco a poco gracias a nuevas tecnologías como LSP, aunque todavía les falta la integración total que tenían en los 90
- Las ventajas de los IDE TUI incluyen acceso remoto, bajo consumo de recursos y libertad del software open source; en cambio, los IDE modernos muestran claramente una tendencia a la hinchazón de funciones
Introducción: nostalgia por los IDE basados en texto de principios de los 90
- Entre finales de los 80 y principios de los 90, el autor volvió a experimentar viejos entornos de desarrollo con DOSBox y disfrutó compararlos con los actuales
- Los IDE basados en texto de entonces tenían muchas funciones a pesar de las limitaciones del hardware
- Después, la mayoría de esas funciones desaparecieron durante mucho tiempo con el ascenso de los sistemas operativos con ventanas, y solo recientemente algunas han comenzado a reaparecer
Primeros editores y entorno TUI
- En los 90, la mayoría de los programas para DOS usaban una Text User Interface (TUI) de pantalla completa, con soporte para ventanas de texto, color, sombras e incluso mouse
- Cada programa tenía un diseño distinto, pero gracias a modos de operación similares era fácil aprenderlos rápidamente
- MS-DOS ofreció un editor TUI integrado desde la versión 5 (1991), pero había que cerrar el editor para compilar/ejecutar, y al volver a abrirlo era incómodo tener que encontrar otra vez la posición de trabajo
- También existían herramientas basadas en TSR (programas residentes) como SideKick Plus (1984), que hacían posible editar código y compilar de forma eficiente en sistemas operativos sin multitarea
- Ya a mediados y finales de los 80 aparecieron IDE tempranos como Turbo Pascal y QuickBASIC, que ofrecían una experiencia de desarrollo integrada
La serie Borland Turbo: la cima del IDE integrado
- Borland Turbo C++, Turbo Assembler, Turbo Pascal y otros estaban dedicados a lenguajes específicos, pero ofrecían una potente TUI de pantalla completa y funciones sólidas
- Funciones principales:
- Resaltado de sintaxis para mejorar la legibilidad del código
- Integración del compilador y advertencias/diagnósticos
- Sistema de proyectos/build y múltiples ventanas
- Depurador (breakpoints, call stack, etc.)
- Ayuda integrada/manual de referencia
- Todas esas funciones ofrecían un entorno autosuficiente e intuitivo incluso sin internet a principios de los 90
Comparación con el entorno Linux de esa época
- Linux también estaba dominado por herramientas basadas en texto, pero las TUI de pantalla completa no eran comunes
- Vim y Emacs, recomendados en libros y comunidades, podían ampliarse funcionalmente, pero para principiantes resultaban poco amigables y nada intuitivos
- Por ejemplo, Emacs tenía problemas como una ventana sin adornos, colores limitados, soporte inestable para mouse y una interfaz de menús difícil y poco familiar
- IDE como Borland Turbo C++ permitían crear un programa “Hello World” y explorar el entorno en cuestión de minutos, incluso sin conocimientos previos
Los IDE basados en texto de hoy
- Hoy, los entornos más parecidos a los viejos IDE TUI son RHIDE, Free Pascal y QB64
- RHIDE es casi idéntico a Turbo C++, pero era solo para DOS y su desarrollo se detuvo
- Free Pascal ofrece soporte para entornos Unix y un entorno integrado potente con calculadora incorporada, tabla ASCII, etc.
- QB64 parece una TUI, pero en realidad es una simulación GUI y no puede ejecutarse en una terminal
- Free Pascal y QB64 siguen desarrollándose hasta tiempos recientes, pero su popularidad es limitada por su exposición a lenguajes antiguos
Un verdadero IDE moderno de consola
- Entre los entornos de desarrollo integrados basados en texto más actuales, Neovim, Doom Emacs y Helix son de los más conocidos
- Gracias a sus múltiples plugins, ofrecen una experiencia de nivel IDE, pero les falta la integración e intuición específicas por lenguaje que tenían los productos de Borland
- Últimamente, GNU Nano y otros llaman la atención como editores TUI simples, pero carecen de funciones de IDE, por lo que se sienten más parecidos a WordStar
- En definitiva, los editores de consola actuales no alcanzan el nivel de experiencia de los 90, o apenas están recuperando funciones de hace 30 años
La necesidad de un IDE TUI
- Aunque las funciones remotas de VSCode son excelentes, un IDE TUI tiene la ventaja de poder usarse de inmediato tras conectarse por SSH a una máquina remota
- Además, la extensión remota de VSCode no es open source y tiene limitaciones porque no funciona en algunos sistemas operativos, como FreeBSD
- Un IDE TUI consume pocos recursos y resulta aún más útil en entornos remotos
Hinchazón y fenómeno de "bloat"
- Borland Turbo C++ incluía todas sus funciones y podía instalarse con menos de 9 MB y funcionar con 640 KB de RAM
- El Doom Emacs actual supera los 500 MB, y los IDE modernos llegan a varios GB, por lo que la hinchazón se ha vuelto grave
- VSCode, con 350 MB, parece bastante liviano, pero al estar basado en Electron consume muchos recursos reales del sistema
- Hay avances en funciones, refactorización y otros aspectos, pero la innovación es limitada en comparación con hace 30 años
- La asistencia de código con IA es un cambio reciente, aunque en la práctica predomina como servicio remoto
Conclusión
- El autor usa distintos entornos de desarrollo según la situación, como Doom Emacs, Vim, VSCode e IntelliJ
- La experiencia de desarrollo todo en uno y la eficiencia que ofrecían los IDE TUI de hace 30 años contrastan claramente con la hinchazón y fragmentación de los IDE modernos
- El valor y el potencial de los IDE basados en texto siguen vigentes, y valdrá la pena observar cómo evolucionan y si realmente resurgen
1 comentarios
Opinión de Hacker News
Me impactó mucho descubrir que Visual Basic era lo mejor en programación gráfica. Antes, en un solo día podías desarrollar rapidísimo una aplicación GUI de nivel intermedio. C# WinForms fue lo más cercano a eso, pero me da pena que todas las herramientas posteriores no hayan pensado en el desarrollador individual. Propongo un nuevo paradigma de desarrollo potente: desarrollo basado en voz/habla (SDD/VDD). Ojalá nos libere del dolor de tanto tecleo y que interactuar con la IA se vuelva tan natural como hablar con un colega. Pero para lograrlo bien, los modelos de IA tendrían que volverse mucho más rápidos
Delphi ya era mejor que Visual Basic en ese entonces, y todavía se puede usar. Lazarus también sigue ahí. De hecho, C# WinForms es lo más parecido a la experiencia de Delphi
Sentí que Qt Creator ofrece una experiencia similar a VB6. Me pregunto si alguien aquí lo ha usado
Sigo pensando que Emacs todavía ofrece todas esas características. Lo que el autor llama “no tradicional” en realidad se debe a convenciones con las que no está familiarizado. Emacs está completamente autodocumentado y es interactivo. La mejor interfaz basada en texto que he usado en mi vida es Magit dentro de Emacs (https://magit.vc/). Ojalá más partes de Emacs fueran como Magit. Aunque use otro IDE, sigo usando Emacs como cliente de git
Emacs es una herramienta con mucha historia, de antes de que Apple desarrollara los atajos cmd-z/x/c/v. En ese tiempo, lo dominante entre los atajos de editores para programadores era la familia Wordstar (por ejemplo, la mayoría de los productos de Borland). Había IDEs sobresalientes hace 30 o 40 años que hoy casi nadie conoce. Por ejemplo, Apple MPW (1986) era un editor GUI donde cada ventana era un shell de Unix, y podías controlar ventanas y tareas de edición con scripts de shell; también incluía un sistema de control de código fuente. Si escribías un comando y presionabas opción-Return, aparecía una ventana GUI llamada 'Commando' donde podías elegir todas las opciones. Apple Dylan (1992-1995) era un IDE potente al estilo Lisp/Smalltalk, y THINK Pascal y C (1986), Metrowerks Codewarrior (1993), y Macintosh Allegro Common Lisp también fueron innovadores. Sorprende que IDEs tan pulidos se hayan implementado en entornos de 8~40MHz M68000 y 2~32MB de RAM en los 80 y principios de los 90
Sobre la idea de que Emacs es autodocumentado e interactivo, en la práctica, cuando lo probé por primera vez ni siquiera era fácil descubrir cómo guardar un documento. Será mejor que vi, pero para que un principiante lo use sin explicaciones, se queda corto
Magit es realmente impresionante. Me pregunto cómo se les ocurrió un modelo de datos así. Se siente como si implementara algo más allá del propio modelo de datos de git. Frente al desorden del porcelain de git, Magit tiene una estructura sistemática
Los IDE estilo Turbo-Vision te dejan entender la mayoría de las funciones con solo conocer unas cuantas teclas como Alt, Tab, Return, Esc y las flechas, mientras que Emacs no tiene esa misma uniformidad operativa
Llevo más de 25 años usando Emacs, así que ya estoy completamente acostumbrado
Turbo Pascal fue realmente increíble. Al principio dudé en usarlo porque era una implementación no estándar de Pascal, pero las herramientas competidoras eran demasiado caras y menos potentes. Cuando lo probé, me enamoró por completo. Fue una experiencia rápida e intuitiva de IDE en una IBM PC. Entre los IDE modernos, Intellij ha sido por mucho mejor que sus competidores durante más de 25 años. Hace mucho que no uso productos de Microsoft, así que no tengo experiencia con VSCode. Eclipse también era lento, poco intuitivo y con muchos bugs. JetBrains es una de esas raras empresas que mantiene su misión y sigue siendo excelente. Impresiona cómo siguen soportando distintos lenguajes, estándares y herramientas sin perder una calidad sobresaliente
Visual Studio todavía soporta WinForms y el diseñador gráfico de formularios, así que se parece muchísimo a la experiencia de Delphi de finales de los 90. WinForms imitó descaradamente a VCL
Pero el problema de consumo de recursos es grande. Como no puedo usar neovim en un escritorio en la nube, terminé usando ideavim, pero incluso con 4 núcleos y 16 GB de RAM, abrir varios proyectos ya hace que todo se trabe. Puede influir el software de seguridad de la empresa, pero con VSCode no se pone así de pesado
El IDE de Turbo Pascal estaba adelantado a su época, y en CP/M (sobre todo Z-80) también era increíble, casi mágico. Era mejor que cualquier otra cosa de su tiempo
El artículo es de 2023, así que el año del título debería actualizarse a 32 años atrás. Lo que más extraño hoy en los TUI es que los frameworks asíncronos a veces ignoran las pulsaciones de teclas. Los TUI anteriores a 2000 esperaban la entrada del teclado aunque el sistema no estuviera listo. En cambio, en los frameworks TUI modernos “basados en web”, si presionas una tecla antes de que se registre el event listener, simplemente se pierde. Fuera de ese tipo de problemas, los TUI siguen funcionando bastante bien. Neovim presume las mejores funciones de su historia gracias a LSP y los plugins. No es un TUI basado en mouse, pero en productividad es excelente
En la era de DOS, en terminales reales había un búfer de entrada del teclado, y quienes dominaban la interfaz metían varias teclas por adelantado y se adelantaban a la UI. La entrada se acumulaba en el búfer y luego aparecía y desaparecía en pantalla en un instante. Esta estructura también se puede implementar con frameworks modernos, pero hay que hacerlo con cuidado
Yo ya tenía esa experiencia en 1984, así que también entra en el rango de hace 41 años. Los proyectos de esa primera época eran los dominantes hasta que aparecieron productos GUI como Visual Studio 1.0 o NetBeans. Es de antes de vim (1991), pero era como querer ventanas flotantes en lugar de ncurses
Este fenómeno de que se pierdan teclas es desesperante. Antes podías usar la computadora a una velocidad brutal con combinaciones rápidas de atajos; ahora se siente como caminar dentro de melaza pegajosa
No tenía claro a qué momento exacto se referían con hace 30 años, pero esperaba que apareciera el navegador de sistemas GUI Smalltalk y en cambio salió un TUI de DOS, lo cual me decepcionó. Aun así, me dio gusto recordar Turbo C/Pascal, MS C 4.0 y CodeView. Estas herramientas se podían usar incluso en modos de 43 y 50 líneas
Creo que depender demasiado de un IDE específico puede perjudicar tanto tu competitividad como tu código. Si hablamos de IDEs de terminal, el terminal de GNU/Linux es la mejor app que existe. Si usas varias terminales en un gestor de ventanas en mosaico, la productividad se dispara. El escalado moderno en pantallas grandes también es excelente desde el punto de vista ergonómico para desarrolladores
Todavía sigo desarrollando y usando un editor/IDE basado en texto que hice yo mismo (https://github.com/alefore/edge). Hace poco escribí las conclusiones de 10 años de desarrollo (https://github.com/alefore/weblog/blob/master/edge/README.md)
En el auge de DOS, los caracteres se manejaban como un arreglo de bytes, y los atributos (fondo, color de texto, etc.) como otro arreglo aparte. Si querías escribir una 'A' en una posición específica, solo tenías que escribir 0x41 en la dirección de memoria. Había algo de wait state, pero era muchísimo más rápido que imprimir con comandos ANSI en una terminal de 9600 baud. Emacs se podía usar en terminales seriales lentas o en el emulador de terminal de estaciones de trabajo Sun, pero eso explica por qué desaparecieron los TUI basados en shell
Aunque este artículo se centra en IDEs basados en texto, creo que también aplica a IDEs tradicionales como Visual Basic o Delphi. Para principiantes, de verdad hace falta un IDE para Python. No algo basado en texto, sino estilo Visual Basic: todo integrado y fácil de descubrir (¡eso es importante!). También sería bueno que incluyera un constructor de GUI y un depurador. El editor de código solo necesitaría resaltado de sintaxis, autocompletado y navegación sencilla por el código. Por ejemplo, poner un botón en una ventana y hacer doble clic en el editor GUI para saltar directo al código del handler de ese botón. Hace tiempo varias personas nos juntamos para hablar de una idea parecida, pero la discusión se desinfló porque no nos poníamos de acuerdo sobre qué framework GUI usar (Pyside, Dear PyGui, basado en web, etc.). Ya que salió el tema de Free Pascal, también habría que mencionar Lazarus (https://www.lazarus-ide.org/), que es una réplica de Delphi. Es muy bueno y sigue en desarrollo activo. Pero como hoy casi no se usa Object Pascal, da una sensación algo anticuada
Estoy totalmente de acuerdo en que hace falta un IDE integrado para Python, estilo Visual Basic, con constructor de GUI y depurador integrado para principiantes. Existió un IDE de Python llamado Boa Constructor (https://boa-constructor.sourceforge.net/) en 2000, pero nunca se popularizó
Yo también grabé hace poco un video creando una app de juguete en Windows 3.11 con VB3, y ese tuit se volvió “viral”. Al final, lo importante no es el TUI, sino la experiencia de uso integrada
Para mí, Lazarus es el estándar de lo que debería ser un IDE de verdad. Lazarus está hecho con Lazarus, y su autor usa a fondo su propio producto, además de ofrecer ejemplos y tutoriales. También es excelente para enseñar programación a niños. Tiene integrados etiquetado, búsqueda, ayuda, documentación de API, ejemplos de widgets y bibliotecas, como Microsoft Visual Studio. Otros IDE no tienen ese nivel de integración, y aunque Xcode diga ser un IDE, al lado de Lazarus se queda corto. Soy tan terco que llevo seis meses haciendo mi propio framework frontend de UI en Go en lugar de JS, y ojalá algún día también pueda hacer un IDE
El IDE de Borland era una auténtica alegría. Todavía no encuentro una herramienta moderna que me dé una experiencia de ese nivel. Claro, puede haber algo de nostalgia, pero incluso inventarme una excusa para usar Free Pascal y volver a sacar esa interfaz ya me da gusto. También me gusta Pascal. A veces uso Sam y Acme de Plan 9, pero eso son editores, no IDEs. Prefiero herramientas que me dejen pensar y no me estorben. Hay mucho que aprender de los viejos TUI. Por ejemplo, desde el menú File podías abrir un shell, ejecutar algo y luego volver; eso era perfectamente aceptable e incluso heroico. ¡Y los atajos de teclado! Los viejos TUI tomaban mucho del patrón de atajos de WordStar, y lo tengo tan metido en el cuerpo que Emacs se siente como escribir con guantes de cocina. Durante mucho tiempo usé joe (alias jstar). Ahora es hora de arrancar una VM con Dr. DOS, hacer unos retos de Advent of Code y darme un festín de nostalgia deliberadamente ineficiente
El software “profesional” de la época de DOS (como Emacs) estaba diseñado para que el usuario viviera por completo dentro de ese software. Podías fusionarte con la máquina y manejar los atajos como un organista. Recuerdo ver a empleados de Fry’s Electronics usar TUI tan rápido que terminaban el trabajo y salía la impresión antes de que siquiera apareciera la pantalla
Me interesa saber qué son exactamente los bindings de WordStar y qué tienen de bueno. Me interesa estudiar la historia de estos patrones y las ventajas de cada enfoque
Coincido con este gran comentario. Yo también estoy desarrollando en mi tiempo libre un editor de código TUI al estilo Turbo Pascal. Más adelante planeo integrar también make y lldb
Me gustan muchas cosas de Plan 9, pero simplemente no logro adaptarme a la UI tan centrada en el mouse de Acme. Una interfaz que exige apuntar con precisión con el mouse debió de ser muy incómoda para usar por mucho tiempo o en caso de discapacidad
La combinación de djgpp y vi for dos 1991 era lo máximo
Usé tanto el IDE de Java Visix Vibe como Delphi, y ambos disparaban muchísimo la productividad. Era fácil estimar tiempos para desarrollar la UI, conectar la lógica y dejar todo listo para desplegar al cliente. Lo que más extraño de ambos IDE es, sobre todo, su nivel de integración. Conectabas una base de datos, generabas formularios, y enseguida podías capturar datos y validarlos. En pocos días podías evolucionar eso a una UI que reflejara los requisitos del proyecto. Hoy hace falta mucha más planeación y reflexión para lograr que UI, API y backend queden bien conectados. Siento que no basta con que la IA genere código de UI; todavía hacen falta herramientas donde uno pueda seguir “dibujando” el código de forma visual y construir el programa desde la interfaz. Si alguien sacara una herramienta WYSIWYG decente para JUCE, creo que volvería una época dorada
En la época de DOS tenías un arreglo de bytes para representar caracteres y otro para los atributos de color, y el hardware dibujaba eso directamente. Bastaba escribir un valor en una dirección de memoria para que apareciera en pantalla, así que era muchísimo más rápido que una terminal serial lenta o que un sistema basado en comandos ANSI. Cuando usabas Emacs en el terminal de una estación Sun, inevitablemente iba a ser lento, y por eso desaparecieron los TUI