IDEs we had 30 years ago

Original Article ↗ Hacker News Discussion ↗

Nostalgia for Borland’s Turbo Pascal and other 80s–90s text‑mode IDEs sparks a broader look at how today’s tools compare to those early, tightly integrated environments. Commenters contrast modern giants like Visual Studio, JetBrains IDEs, VS Code, Vim/Emacs and Eclipse with old TUIs in terms of startup speed, debuggers, GUI builders, remote work, and configurability, often arguing that while features have expanded, usability, performance and cohesiveness have not always improved. Many conclude that language servers and powerful GUIs bring clear gains, but that the simplicity, responsiveness and “batteries‑included” feel of classic IDEs remain largely unmatched.

Scope of the discussion

  • Thread reflects on 80s–90s IDEs (especially Borland/Turbo) and compares them to modern IDEs, editors, and workflows.
  • Major sub-themes: GUI vs TUI IDEs, Eclipse/NetBeans/JetBrains/VSCode debates, Vim/Emacs culture, remote development, debugging, and RAD GUI builders like Delphi/VB6.

Borland, Turbo Pascal/C, Delphi and old-school IDEs

  • Many recall Turbo Pascal/C/C++ as fast, intuitive, and beginner-friendly, with excellent integrated debuggers and manuals.
  • Delphi and VB6 are repeatedly cited as peak RAD GUI tools; people argue building native GUIs was dramatically faster and simpler than today’s web/mobile stacks.
  • FoxPro, PowerBuilder, QBasic, THINK C, CodeWarrior, and various Amiga/C64/Atari tools are also remembered as powerful, tightly integrated environments.
  • Several note that deep, well-written printed manuals and offline docs built stronger mental models than today’s snippet-driven web docs.

“Forgotten” advanced GUI IDEs (Smalltalk, Lisp, NeXT, etc.)

  • Commenters argue that the article underplays GUI IDEs: Smalltalk systems, Interlisp-D, Mesa/Cedar, Lisp Machines, EiffelStudio, NeXT Interface Builder, Symbolics Genera, and early Mac IDEs are described as decades ahead in integration and live tooling.
  • Some claim Smalltalk-like systems have consistently been among the most advanced IDE experiences, with image-based workflows and rich inspectors.

Eclipse, NetBeans, JetBrains, VSCode and modern IDEs

  • Strong split on Eclipse:
    • Fans: call it efficient, feature-rich, stable in recent years, with powerful indexing, LSP, strong C++ support, and reproducible workspaces; some use vendor IDEs based on Eclipse.
    • Critics: remember it as bloated, slow, plugin-hell, painful to maintain; many migrated to IntelliJ or VSCode and “never looked back.”
  • NetBeans is remembered fondly (especially for Java, Swing GUI builder, profiling); some feel it declined post-Oracle or as Apache NetBeans.
  • JetBrains IDEs (IntelliJ, CLion, RubyMine, etc.) are widely praised for deep static analysis, refactoring, and “just works” integration with ecosystems; memory use is accepted by many as the cost of power.
  • VSCode is seen by some as “text editor in IDE clothing” but wins on UX, extensions, and especially remote dev; others dislike its model, Electron overhead, or ergonomics.
  • Opinions differ on dark mode and aesthetics:
    • Some argue IntelliJ and VSCode “won” partly by being early with attractive dark themes.
    • Others insist functionality and performance mattered far more than theme.

Vim, Emacs, Neovim, Helix and editor philosophy

  • Many use Vim/Emacs (often for decades) and value:
    • Modal or keyboard-centric editing, macros, composable commands.
    • Universal availability (especially over SSH, on servers, and at large companies with custom tooling).
    • Extensibility and the strength of long-lived open-source communities.
  • Others, especially in mid-career, say they lack time/energy to master Emacs/Vim; prefer JetBrains/VSCode/Visual Studio “out of the box”.
  • LSP/DAP are seen as transformative, bringing “IDE-grade” completion, navigation, and refactoring into generic editors (vim, emacs, Helix, etc.).
  • There is debate over whether turning Vim into a full IDE via plugins is worth the configuration and breakage vs. using a dedicated IDE with Vim keybindings.

Remote development: TUI vs VSCode remote

  • One camp argues TUI editors + SSH + tmux are unbeatable for remote work, especially on low bandwidth or constrained environments.
  • Another camp strongly prefers VSCode’s remote model (frontend local, backend remote), citing:
    • Local handling of cursor movement and selection, avoiding round-trip lag.
    • Asynchronous saves/builds, better integration with local OS features, and easier UX.
  • Emacs TRAMP, SSHFS/FUSE, mosh, and remote terminals are discussed as alternatives; some find TRAMP slow or brittle at scale.
  • There is extended debate comparing X11-style remote GUIs vs VSCode’s remote protocol; several stress that VSCode avoids per-keystroke round trips that plague classic remote GUIs.

Debugging and tooling quality

  • Many feel debugging has regressed on Unix/Linux compared to integrated DOS/Windows IDEs:
    • gdb is powerful but seen as cumbersome; some miss simple, integrated visual debuggers.
    • Visual Studio and Xcode are viewed as still having top-tier debuggers and tooling.
  • Old commercial Unix tools (dbx, DDD, Sun/Solaris IDEs) are mentioned as historically good but largely forgotten.

RAD GUI builders and their decline

  • Several lament that nothing today matches Delphi/VB6 (and similar tools) for quickly building native desktop GUIs with data binding, live design-time data, and component ecosystems.
  • Lazarus/FreePascal is seen as a spiritual successor, but:
    • Considered behind web tech in visual “eye candy” and UX expectations.
    • Documentation and polish are viewed as weak; some fear the project is stagnating.
  • Some note that cross-platform complexity, security, and deployment concerns (and the shift to web/mobile) contributed to the decline of “VB/Delphi-style” RAD.

Culture, FAANG, and “terminal-based” workflows

  • Several associate FAANG-style/server-heavy development with:
    • Preference for terminal tools (Vim/Emacs, CLI build systems).
    • Internal custom tooling, build systems, and languages where transferrable editors are valuable.
  • Advice is often “pick an editor and go deep”; some add “pick a company that lets you use your editor.”
  • Others argue IDEs remain underused and people “miss out” by sticking to only terminal tools.

Documentation, manuals, and learning

  • Nostalgia for thick printed manuals and self-contained documentation that explained concepts, not just recipes.
  • Multiple people criticize modern docs as step-focused (“do X, then Y”) without building domain models; this is seen as encouraging copy-paste coding.
  • Some recount being told to remove “why” explanations from internal docs to avoid “confusing” readers, and feel this makes documentation worse.

UI, accessibility, and small UX details

  • Several complain about modern minimalistic scrollbars (tiny, auto-hiding), especially on touch devices or for accessibility; older UIs with visible, thick scrollbars are preferred.
  • General sense that aesthetics and “on-trend” design have sometimes trumped usability and information density in modern tools.

Overall sense of progress

  • Mixed verdict:
    • IDE features (static analysis, refactoring, cross-language LSP, debugging for some platforms) are seen as more powerful than ever.
    • Yet many feel certain qualities from 80s/90s tools—speed, cohesion, debuggability, RAD GUI building, simplicity, and strong docs—have been lost or are harder to find in today’s fragmented, heavier ecosystems.