The IDEs we had 30 years ago ... and we lost
161 comments
·October 18, 2025CGamesPlay
cameldrv
Yes. Back in the DOS days, and even before, when people used actual terminals, there was a keystroke buffer. You'd see people who really knew the interface fly through tasks being multiple keystrokes ahead of the UI. Stuff would just flash onto the screen and disappear as it processed the input that was already in its buffer. It should be possible to implement this with modern frameworks, but it requires thought.
heresie-dabord
When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself.
> As for terminal IDEs
The GNU/Linux terminal is the killer app. Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.)
And modern scaling for a big display is unbeatable for developer erogomics.
a3w
Rough quote: "in 1984 we had at my house",
so even 41 years seems to be in the scope.
I was expecting
- early projects that ended in Visual Studio 1.0 or NetBeans soon after, (2 to 9 years too early for them)
not
- "vim (1991) was not out yet" (not-a-quote, but my feeiling upon looking at ncurses instead of floating windows)
karmakaze
I wasn't paying attention to when 30 years ago actually was...
So disappointing to expect a GUI Smalltalk System Browser and seeing DOS TUIs.
And then delight recalling Turbo C/Pascal and MS C 4.0 with CodeView that even worked in 43 or 50 line modes.
mkovach
Ah, Borland’s IDE! An absolute delight. I’ve yet to find anything modern that matches it. Sure, nostalgia turns everything syrupy, but I actively hunt for excuses to use Free Pascal just to fire up that interface. Okay, fine—I like Pascal too. You caught me.
I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think instead of wrestle.
There’s a lot we could (and probably should) learn from the old TUIs. For example, it’s perfectly acceptable, even heroic, to spawn a shell from the File menu and run something before returning. Seems people are afraid of losing style points with such grievous actions.
And the keybindings! So many of those classic TUIs adopted WordStar’s sacred keystrokes. They’re burned into my muscle memory so thoroughly that using EMACS feels like trying to type with oven mitts. For years, joe (with the blessed jstar alias) was my editor of choice.
Anyway! Time to boot the Dr. DOS VM, spin the wheel of Advent of Code, and be nostalgically inefficient on purpose.
bombcar
One thing about the "professional" DOS software (and you can see it in things like Emacs - eight modes and constantly shifting) was you were basically expected to live in it - it had the full attention of the computer and the user.
You were also expected to learn it; which meant you became "one with the machine" in a way similar to an organ player.
I remember watching Fry's Electronics employees fly through their TUI, so fast that they'd walk away while it was still loading screens, and eventually a printout would come out for the cage.
Aurornis
> it had the full attention of the computer and the user.
This why I like to use the full screen mode of my editors and IDEs.
It surprises a lot of people who see my screen. Full screen features are everywhere but rarely used.
Mountain_Skies
About twenty years ago I did a consulting gig for a government agency that wanted to create a web interface for their CSRs to replace the green screens they had been using. The long time employees hated it because they had deep muscle memory for most tasks on the green screens and could get far ahead of the screen refresh. With the web UI, not only could they not type ahead, but many of the workflows now required use of the mouse.
The agency was happy to have something new and modern but more important to them was that new employees could be trained on the system far faster. Even though there were a small number of long term employees, they had high turnover with the frontline CSRs, which made training a major issue for them.
esafak
The old TUIs were faster yet I still prefer IntelliJ; it's fast enough and much more powerful.
exe34
Even normal windows applications used to be like this (outside of crashing). I could alt-tab, type stuff and click where I know a button would show before I even saw the application window. It never missed a key stroke or type into the wrong window. Nowadays you load a webpage and start typing, and half you text appears and then the other half just never shows up.
citbl
What a wonderful write up and I feel the same.
I've been working on my free time on a tui code editor in the same vein eventually with make and lldb built in.
dimitar
I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive.
For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.
I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.
brucehoult
The thing is that emacs predates Apple developing cmd-z/x/c/v and Microsoft copying Apple in Windows. Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.
Also OP apparently has no knowledge of the far better IDEs we had 30-40 years ago including but not limited to:
- Apple MPW, 1986. GUI editor where every window is (potentially) a Unix-like shell, running commands if you hit Enter (or cmd-Return) instead of Return. Also the shell scripting has commands for manipulating windows, running editing actions inside them etc. Kind of like elisp but with shell syntax. There's an integrated source code management system called Projector. If you type a command name, with or without arguments and switches, and then hit option-Return then it pops up a "Commando" window with a GUI with checkboxes and menus etc for all options for that command, with anything you'd already typed already filled out. It was easy to set up Commando for your own programs too.
- Apple Dylan, 1992-1995. Incredible Lisp/Smalltalk-like IDE for Apple's Dylan language
- THINK Pascal and C, 1986. The Pascal version was orginaly an interpreter, I think written for Apple, but then became a lightning-fast compiler, similar to Borland on CP/M and MS-DOS but better (and GUI). The C IDE later became a Symantec product.
- Metrowerks Codewarrior, 1993. Ex THINK/Symantec people starting a Mac IDE from scratch, incorporating first Metrowerks' M68000 compilers for the Amiga, then a new PowerPC back end. Great IDE, great compilers -- the first anywhere to compile Stepanov's STL with zero overhead -- and with a groundbreaking application framework called PowerPlant that heavily leaned on new C++ features. It was THE PowerPC development environment, especially after Symantec's buggy PoS version 6.
- Macintosh Allegro Common Lisp (later dropped the "Allegro"), 1987. A great Mac IDE. A great Lisp compiler and environment. Combined in one place. It was expensive but allowed amazing productivity in custom native Mac application development, far ahead of the Pascal / C / C++ environments. Absolutely perfect for consultants.
Really, it is absolutely incredible how slick and sophisticated a lot of these were, developed on 8 MHz to 33 or 40 MHz M68000s with from 2-4 MB RAM up to maybe 16-32 MB. (A lot of the Mac II line (and SE/30) theoretically supported 128 MB RAM, but no one could afford that much even once big enough SIMs were were available.)
dapperdrake
Magit is mind blowing.
How did the magit guy or people even come up with the data model? Always had the feeling that it went beyond the git data model. And git porcelain is just a pile of shards.
nobleach
For reference, I did use Magit for my short stint with Emacs (and then Spacemacs/Doom Emacs). I've always been more into Vim. I tried the Atom editor several years ago with lots of Vim emulation and quite a bit of customization - one of those being a Magit clone.
I moved to NeoVim many years ago and have been using NeoGit (a supposed Magit clone) the entire time. It's good but I'm missing the "mind blowing" part. I'd love to learn more though! What features are you using that you consider amazing?
bigstrat2003
> It is however fully self-documented and interactive.
Unfortunately not true. I've fired up emacs once or twice, and couldn't even figure out how to save a document because it didn't show me how to do that. It might be more documented than vi (but that bar is *on the floor, vi has one of the most discovery-hostile user interfaces ever made), but it's not self-documented enough to just pick up and use with no instruction.
krs_
That's a fair criticism, although once you learn how to access the documentation and where to look for/expext it I find that most things, including add-on packages and whatnot, can be learned from within Emacs itself just fine. But it does take some knowledge to get to that point in the first place for sure.
rbanffy
> it just uses conventions he is not used to.
It just came up with conventions few others adopted later when they reinvented the wheel.
jmmv
> it just uses conventions he is not used to
I think that after 25+ years of usage, I'm "used to it" by now.
creddit
The Magit experience is due to the use of the transient package for its UI.
Some other packages also use it. Most notably for my personal usage is the gptel package.
tarsius
> The Magit experience is due to the use of the transient package for its UI.
(I'm the author of Magit and Transient. (Though not the original author of Magit.))
The transient menus certainly play an important role but I think other characteristics are equally important.
A few years ago I tried to provide an abstract overview of Magit's "interface concepts": https://emacsair.me/2017/09/01/the-magical-git-interface/. (If it sounds a bit like a sales pitch, that's because it is; I wrote it for the Kickstarter campain.)
pkal
Transient is the worst part about Magit IMO (the best parts are how you can prepare a commit to just include the right changes, or the functionality bound inside the transient menus that make complex operations such as fixups or rebases trivial). Transient UIs are consistently uncomfortable to work with, and could usually be replaced by just using a regular special-mode keymap in a custom buffer. The fact that Transient hooks into the MVC and breaks elementary navigation such as using isearch or switching around buffers has irritated me ever since Magit adopted the new interface.
The real neat thing about Emacs' text interface is that it is just text that you can consistently manipulate and interact with. It is precisely the fact that I can isearch, use Occur write out a region to a file, diff two buffers, use find-file-at-point, etc. that makes it so interesting to me at least.
A far more interesting example than Magit is the compile buffer (from M-x compile): This is just a regular text buffer with a specific major mode that highlights compiler errors so that you can follow them to the referenced files (thereby relegating line-numbers to an implementation detail that you don't have to show the user at all times). But you can also save the buffer, with the output from whatever the command was onto disk. If you then decide to re-open the buffer again at whatever point, it still all looks just as highlighted as before (where the point is not that it just uses color for it's own sake, but to semantically highlight what different parts of the buffer signify) and you can even just press "g" -- the conventional "revert" key -- to run the compile job again, with the same command as you ran the last time. This works because all the state is syntactically present in the file (from the file local variable that indicates the major mode to the error messages that Emacs can recognize), and doesn't have to be stored outside of the file in in-memory data structures that are lost when you close Emacs/reboot your system. The same applies to grepping btw, as M-x grep uses a major mode that inherits the compile-mode.
tarsius
> Transient UIs [...] could usually be replaced by just using a regular special-mode keymap in a custom buffer.
For people who can look at a list of key bindings once and have them memorized, maybe. Turns out most people are not like that, and appreciate an interface that accounts for that.
You also completely ignore that the menus are used to set arguments to be used by the command subsequently invoked, and that the enabled/disabled arguments and their values can be remembered for future invocations.
> The fact that Transient hooks into the MVC and breaks elementary navigation such as using isearch
Not true. (Try it.) This was true for very early versions; it hasn't been true for years.
> or switching around buffers
Since you earlier said that transient menus could be replaced with regular prefix keys, it seems appropriate to point out that transient menus share this "defect" with regular prefix keys, see https://github.com/magit/transient/issues/17#issuecomment-46.... (Except that in the case of transient you actually can enable such buffer switching, it's just strongly discouraged because you are going to shoot yourself in the foot if you do that, but if you really want to you can, see https://github.com/magit/transient/issues/114#issuecomment-8....
> has irritated me ever since Magit adopted the new interface.
I usually do not respond to posts like this (anymore), but sometimes the urge is just too strong.
I have grown increasingly irritated by your behavior over the last few weeks. Your suggestion to add my cond-let* to Emacs had a list of things "you are doing wrong" attached. You followed that up on Mastodon with (paraphrasing) "I'm gonna stop using Magit because it's got a sick new dependency". Not satisfied with throwing out my unconventional syntax suggestion, you are now actively working on making cond-let* as bad as possible. And now you are recycling some old misconceptions about Transient, which can at best be described as half-truths.
dimitar
Indeed! I went back just to mention it owes its incredible UX to the transient package, I am going to look up more uses for it. Do recommend more if you can, please!
layer8
To navigate a Turbo-Vision-style IDE and explore its functionality, you basically only need to know how the Alt and Tab keys work (okay, and Return and Esc and arrow keys), as alluded to in TFA. Emacs doesn’t quite have that base level of operating uniformity I think.
JoelMcCracken
To navigate emacs, you really only need to know ctrl, alt, and the basic norms of keyboard usage (return for newline/accept, shift for capitals)
Really, compared to what I see here, the chief difficulty with emacs is the sheer volume of possible commands, and the heterogeneity of their names and patterns, which I believe is all a result of its development history. But the basics are just as you describe.
skydhash
The base input of emacs is ‘M-x’. From there, any command is accessible. And you have ‘M-:’ for evaluating any bit of elisp code. There’s a few UI concepts to learn (frame, window, buffers, point, mark, region,…), but that would fit in a single sheet of paper.
layer8
The keys I enumerated are sufficient to discover and execute all available operations in that style of TUI. You don’t have to type commands or command-specific keyboard shortcuts, like you have to in Emacs. It’s analogous to how in a traditional GUI you can discover and execute everything just using the mouse.
Like in the GUI analogy, you can then choose to remember and use the displayed keyboard shortcuts for frequently used operations, but you don’t have to.
pjmlp
Back in the day I had to use XEmacs as it was more advanced as plain Emacs.
After IDEs finally started being a common thing in UNIX systems, I left Emacs behind back to IDEs.
Still I have almost a decade where Emacs variants and vi were the only option, ignoring stuff like joe, nano, ed, even more limited.
haolez
The fun thing is that, if something like Claude Code can be competitive with modern IDEs, these ancient IDEs could become competitive as well with some kind of integration with AI workflows :)
chuckadams
I learned C by right-clicking on all the things in Turbo C on a 286. Learned a fair bit of lisp from emacs using C-h f. I do love the navigation capabilities modern IDEs have, but they don't seem to have the same discoverability.
afc
For what it's worth it, I'm still developing and using exclusively my own text-based editor/IDE: https://github.com/alefore/edge
I wrote recently a bit about my conclusions after ten years of developing it: https://github.com/alefore/weblog/blob/master/edge/README.md
ivanjermakov
Me too. It took ~4 months of development, but was fun.
PaulHoule
In the golden age of DOS you had an array of bytes representing characters and an array representing attributes (background and foreground colors) and the hardware drew out of that. If you wanted to write a ‘A’ to a certain spot you wrote 0x41 to a certain memory address and that was that —- there were some wait states involved but it was way faster than drawing on a 9600 baud terminal with ANSI terminal commands that use up even more bytes.
I first used emacs on terminals that were hooked to Sun workstations and you were either going to use a serial terminal which was very slow, or the terminal emulator on the Sun which was a GUI program that had to do a lot of work to draw the characters into the bitmap. So that’s your reason TUIs went away.
floam
Damn that actually sounds superior. How did changing the size work?
layer8
Unless the program specifically allowed for it, you couldn’t change the size (video mode, really) without exiting and restarting the program after changing modes on the DOS prompt.
Remember, the video hardware rendered text mode full-screen, and it had to be reconfigured to change to a different number of lines and columns. Only specific sizes were supported.
Lapel2742
> “In my house”, we used something called SideKick Plus (1984), which wasn’t really a code editor: it was more of a Personal Information Management (PIM) system with a built-in notepad.
Finally! Someone who still remembers the best software ever written. I looooved Sidekick and we used it throughout our small company. It's so long ago. I remember only parts of it now but it was such a useful tool.
MomsAVoxell
I used to use a Java-oriented IDE called “Visix Vibe”, at first as an experiment in application development with Java and then as an alternative to Delphi, which was my bread and butter tooling environment for custom application development.
Both of these IDE’s gave me a huge productivity boost, and it used to be a no-brainer to give customers a realizable estimate for getting the UI done, then wiring up logic, and get things ready to ship, etc.
I really miss these IDE’s, because of the integration factor. It was fun to wire up a database table and generate a form and immediately have something that could be used for data input and validation on the project - then spend a few weeks refining the UI to be more robust and cater to the application use case in focus.
These days, it feels like a lot more careful planning is needed to make sure the UI/API/backend realms can play properly together.
It would be nice to see some more progress on this level of tooling. It’s one thing to have an AI generate UI code - but I still think there is room for painting the code and using a UI to build a UI.
(The moment someone produces a properly WYSIWYG tool for JUCE, the glory days will begin again ..)
dapperdrake
You may laugh, but that is how I use html forms today. Simple. And effective.
nhatcher
Worth mentioning a version of ms Edit is now opensource. Not only that, it is extraordinary code to learn from:
[1]: https://github.com/microsoft/edit [2]: https://news.ycombinator.com/item?id=44031529
self_awareness
I wouldn't learn from it, since it uses unsafe code even for basic stuff, like hash calculation.
It's also a complete reimplementation, it shares only the name with original edit.com.
nhatcher
Well, you wouldn't learn as is let's learn Rust from it. But I think it has many interesting bits not found in most open source projects out there. and true that, there is a lot of unsafe code, uses nightly builds, its own allocator, crazy stuff. I did learn a lot from it :)
And yeah, it is a reimplemantion. But it is a TUI and very minimal. Keepining it minimal, with no dependendecies and software bloat seems to be one of the guidelines. So very much something adding to the article at case.
But yeah, you are right on both counts.
coldcode
I used Borland Turbo Pascal in 1984. It was amazing to work with something so fast on a PC that was really so slow. No IDE/Compiler since then matched the speed. Today's code is massively more sophisticated and complex, so there is no way to match that performance today despite the speed of computers today.
elevation
I got a windows 95 66MHz Pentium machine with 16MB ram at a yard sale in 2002. Visual Studio 5 Enterprise worked plenty fast on that with features I still miss (or which don’t perform as well) in modern environments.
chadcmulligan
Have you tried Delphi lately, very fast, compiles in less than a second.
1313ed01
Came here to share this mandatory link on this subject, Dadgm's Things That Turbo Pascal is Smaller Than: https://prog21.dadgum.com/116.html
I used Turbo Pascal 2 as late as 1991, if not later, because that was the version we had. It was really fast on a 386 40 MHz or whatever exact type of PC we had then. A bit limiting perhaps that it only came with a library for CGA graphics, but on the other hand it made everything simpler and it was good for learning.
A few years ago I wanted to run my old Turbo Pascal games and decided to port to Free Pascal. Sadly Free Pascal turned out to only ship with the graphics library introduced in Turbo Pascal 4, but on the other hand I got a few hours of fun figuring out how to implement the Turbo Pascal 1-3 graphics API using inclined assembler to draw CGA graphics, and then my games worked (not very fun games to be honest; more fun to implement that API).
marstall
totally. so strange that that was the fastest, most flowy dev experience i've ever had. been chasing that ever since. though i must say rails, vite, react fast refresh, etc. are pretty nice in that regard.
jmmv
Hey, thanks for sharing this again! FYI, previous discussion from 2 years ago now (wow, time flies...): https://news.ycombinator.com/item?id=38792446
(Article is from 2023, so the title should be updated to say "32 years ago", or something)
The biggest loss in TUIS is the latest wave of asynchronous frameworks, which bring the joy of dropped keypresses to the terminal.
In any TUI released before the year 2000, if you press a key when the system wasn't ready, the key would just wait until the system was ready. Many TUIs today still do this, but increasingly frequently (with the modern "web-inspired" TUI frameworks), the system will be ready to take your keypress, and discard it because the async dialog box hasn't registered its event listener yet.
Other than that antipattern, TUIs are doing great these days. As for terminal IDEs, Neovim has never been more featureful, with LSPs and other plugins giving all the features this article discusses. I guess it isn't a mouse-driven TUI, so the author wouldn't be interested, but still.