Los IDE que teníamos hace 30 años

Artículo original ↗ Discusión en Hacker News ↗

La nostalgia por Turbo Pascal y otros IDE de modo texto de los 80 y 90 impulsa una mirada más amplia a cómo se comparan las herramientas actuales con aquellos entornos tempranos y estrechamente integrados. Los comentaristas contrastan gigantes modernos como Visual Studio, los IDE de JetBrains, VS Code, Vim/Emacs y Eclipse con los antiguos TUI en términos de velocidad de arranque, depuradores, constructores de GUI, trabajo remoto y configurabilidad, y a menudo sostienen que, aunque las funciones han crecido, la usabilidad, el rendimiento y la cohesión no siempre han mejorado. Muchos concluyen que los servidores de lenguaje y las GUI potentes aportan ganancias claras, pero que la simplicidad, la capacidad de respuesta y la sensación de “todo incluido” de los IDE clásicos siguen siendo en gran medida insuperadas.

Alcance de la discusión

  • El hilo reflexiona sobre los IDE de los 80 y 90 (especialmente Borland/Turbo) y los compara con IDE, editores y flujos de trabajo modernos.
  • Subtemas principales: IDE con GUI frente a TUI, debates sobre Eclipse/NetBeans/JetBrains/VSCode, cultura de Vim/Emacs, desarrollo remoto, depuración y constructores de GUI RAD como Delphi/VB6.

Borland, Turbo Pascal/C, Delphi y los IDE de la vieja escuela

  • Muchos recuerdan Turbo Pascal/C/C++ como rápidos, intuitivos y aptos para principiantes, con excelentes depuradores integrados y manuales.
  • Delphi y VB6 se citan repetidamente como herramientas RAD para GUI en su punto álgido; la gente argumenta que construir GUI nativas era drásticamente más rápido y simple que las pilas web/móviles de hoy.
  • FoxPro, PowerBuilder, QBasic, THINK C, CodeWarrior y varias herramientas de Amiga/C64/Atari también se recuerdan como entornos potentes y estrechamente integrados.
  • Varios señalan que unos manuales impresos profundos y bien escritos, junto con documentación offline, construían modelos mentales más sólidos que la documentación web actual basada en fragmentos.

IDE de GUI avanzados “olvidados” (Smalltalk, Lisp, NeXT, etc.)

  • Los comentaristas sostienen que el artículo subestima los IDE de GUI: los sistemas Smalltalk, Interlisp-D, Mesa/Cedar, Lisp Machines, EiffelStudio, NeXT Interface Builder, Symbolics Genera y los primeros IDE de Mac se describen como décadas adelantados en integración y herramientas vivas.
  • Algunos afirman que los sistemas tipo Smalltalk han estado entre las experiencias de IDE más avanzadas de forma constante, con flujos de trabajo basados en imágenes e inspectores ricos.

Eclipse, NetBeans, JetBrains, VSCode e IDE modernos

  • Hay una fuerte división sobre Eclipse:
    • Sus defensores: lo describen como eficiente, rico en funciones, estable en los últimos años, con indexación potente, LSP, gran soporte para C++ y espacios de trabajo reproducibles; algunos usan IDE de proveedores basados en Eclipse.
    • Sus críticos: lo recuerdan como hinchado, lento, un infierno de plugins y doloroso de mantener; muchos migraron a IntelliJ o VSCode y “nunca miraron atrás”.
  • NetBeans se recuerda con cariño (especialmente para Java, el generador visual de Swing, el perfilado); algunos sienten que declinó después de Oracle o como Apache NetBeans.
  • Los IDE de JetBrains (IntelliJ, CLion, RubyMine, etc.) son ampliamente elogiados por su análisis estático profundo, refactorización e integración que “simplemente funciona” con los ecosistemas; para muchos, el uso de memoria se acepta como el precio del poder.
  • VSCode se ve por algunos como un “editor de texto disfrazado de IDE”, pero gana por su UX, extensiones y, especialmente, el desarrollo remoto; otros no soportan su modelo, la sobrecarga de Electron o su ergonomía.
  • Hay opiniones distintas sobre el modo oscuro y la estética:
    • Algunos sostienen que IntelliJ y VSCode “ganaron” en parte por ser tempranos con temas oscuros atractivos.
    • Otros insisten en que la funcionalidad y el rendimiento importaban mucho más que el tema.

Vim, Emacs, Neovim, Helix y la filosofía del editor

  • Muchos usan Vim/Emacs (a menudo desde hace décadas) y valoran:
    • Edición modal o centrada en el teclado, macros y comandos componibles.
    • Disponibilidad universal (especialmente por SSH, en servidores y en grandes empresas con herramientas personalizadas).
    • Extensibilidad y la fuerza de comunidades de código abierto de larga vida.
  • Otros, especialmente a mitad de carrera, dicen no tener tiempo ni energía para dominar Emacs/Vim; prefieren JetBrains/VSCode/Visual Studio “listos para usar”.
  • LSP/DAP se consideran transformadores, llevando completado, navegación y refactorización de “nivel IDE” a editores genéricos (vim, emacs, Helix, etc.).
  • Hay debate sobre si convertir Vim en un IDE completo mediante plugins merece la pena por la configuración y las roturas frente a usar un IDE dedicado con atajos de Vim.

Desarrollo remoto: TUI frente a VSCode remoto

  • Un bando sostiene que los editores TUI + SSH + tmux son insuperables para el trabajo remoto, especialmente con poco ancho de banda o en entornos limitados.
  • Otro bando prefiere con fuerza el modelo remoto de VSCode (frontend local, backend remoto), citando:
    • Manejo local del movimiento del cursor y la selección, evitando la latencia de ida y vuelta.
    • Guardados/compilaciones asíncronos, mejor integración con funciones locales del sistema operativo y una UX más fácil.
  • Se discuten Emacs TRAMP, SSHFS/FUSE, mosh y terminales remotos como alternativas; algunos encuentran TRAMP lento o frágil a escala.
  • Hay un debate extendido comparando las GUIs remotas estilo X11 con el protocolo remoto de VSCode; varios subrayan que VSCode evita las idas y vueltas por pulsación de tecla que plagan las GUIs remotas clásicas.

Depuración y calidad de las herramientas

  • Muchos sienten que la depuración ha retrocedido en Unix/Linux frente a los IDE integrados de DOS/Windows:
    • gdb es potente pero se ve como engorroso; algunos echan de menos depuradores visuales simples e integrados.
    • Visual Studio y Xcode siguen considerándose con depuradores y herramientas de primer nivel.
  • Se mencionan antiguas herramientas comerciales de Unix (dbx, DDD, IDE de Sun/Solaris) como históricamente buenas pero en gran parte olvidadas.

Constructores de GUI RAD y su declive

  • Varios lamentan que hoy nada iguale a Delphi/VB6 (y herramientas similares) para construir rápidamente GUI nativas de escritorio con binding de datos, datos en vivo en tiempo de diseño y ecosistemas de componentes.
  • Lazarus/FreePascal se ve como un sucesor espiritual, pero:
    • Se considera por detrás de la tecnología web en “efectos visuales” y expectativas de UX.
    • La documentación y el pulido se consideran débiles; algunos temen que el proyecto se esté estancando.
  • Algunos señalan que la complejidad multiplataforma, la seguridad y las preocupaciones de despliegue (y el cambio hacia web/móvil) contribuyeron al declive del RAD “al estilo VB/Delphi”.

Cultura, FAANG y flujos de trabajo “basados en terminal”

  • Varios asocian el desarrollo al estilo FAANG o muy centrado en servidores con:
    • Preferencia por herramientas de terminal (Vim/Emacs, sistemas de compilación CLI).
    • Herramientas internas personalizadas, sistemas de compilación y lenguajes donde son valiosos editores portables.
  • El consejo suele ser “elige un editor y ve a fondo”; algunos añaden “elige una empresa que te deje usar tu editor”.
  • Otros argumentan que los IDE siguen infrautilizados y que la gente “se pierde mucho” por quedarse solo con herramientas de terminal.

Documentación, manuales y aprendizaje

  • Nostalgia por los manuales impresos gruesos y la documentación autocontenida que explicaba conceptos, no solo recetas.
  • Varias personas critican la documentación moderna por centrarse en pasos (“haz X, luego Y”) sin construir modelos de dominio; esto se ve como una invitación al copiar y pegar código.
  • Algunos cuentan que les dijeron que eliminaran explicaciones de “por qué” de la documentación interna para evitar “confundir” a los lectores, y sienten que eso empeora la documentación.

UI, accesibilidad y pequeños detalles de UX

  • Varios se quejan de las barras de desplazamiento minimalistas modernas (pequeñas, que se ocultan automáticamente), especialmente en dispositivos táctiles o por accesibilidad; se prefieren las UIs antiguas con barras visibles y gruesas.
  • Hay una sensación general de que la estética y el diseño “de tendencia” a veces han prevalecido sobre la usabilidad y la densidad de información en las herramientas modernas.

Sensación general de progreso

  • Veredicto mixto:
    • Las funciones de los IDE (análisis estático, refactorización, LSP multiplataforma, depuración para algunas plataformas) se consideran más potentes que nunca.
    • Sin embargo, muchos sienten que ciertas cualidades de las herramientas de los 80 y 90 —velocidad, cohesión, capacidad de depuración, construcción RAD de GUI, simplicidad y documentación sólida— se han perdido o son más difíciles de encontrar en los ecosistemas actuales, más fragmentados y pesados.