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 :)
IDEs we had 30 years ago and lost (2023)
161–170 of 607 posts
Re: IDEs we had 30 years ago and lost (2023)
#162(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 frequen…
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.
Re: IDEs we had 30 years ago and lost (2023)
#163Earlier quoted context omitted.
As someone who has been doing this either professionally (since 1996) or as a hobbyist programming in assembly and a little Basic (1986-1992), I’m always amazed at the feigned Slashdot style “I haven’t owned a Tv in 40 years why do people still watch them”. Are you really saying that you don’t see any utility in modern IDEs? Even back in 1999 I thought Visual Studio was a breath of fresh air let alone R# with all of…
What I'm saying is that they can't do anything I can't do in a terminal. Another way of putting it is why would I need an IDE other than UNIX (GNU) itself? > But going further back, to the Turbo days in college and my first few years working, breakpoints, conditional breakpoints, watches etc were a godsend gdb does all of that.
Because working in an IDE is an order of magnitude easier than with UNIX tools, especially for novices, significantly increasing productivity. The author also covers this a bit.
Re: IDEs we had 30 years ago and lost (2023)
#164I 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.
Magit is really great, however, it can definitely be quite slow and buggy sometimes
Re: IDEs we had 30 years ago and lost (2023)
#165Good article. I'm more of a GUI guy who is contend with VSCode. I'm intrigued to learn Emacs but don't have the time for it. Back in the 90s, however, Borland TUI was indeed the pinnacle. I remember I played with Turbo C for a while but did not learn anything, but it was fun just to use the IDE.
I think that GUI editors are just plain superior for doing serious work. I'm a Sublime guy myself, but really any GUI editor blows any text based option out of the water. The only good use case for text based editors these days is to quickly edit and save config files while ssh'ed into a server.
I heard people can be pretty productive in Emacs/Vim. My issue is that I’m not a great programmer, so 99% of the time is spent on reading code and figuring out the steps on paper. I’m sure TUI can be great for that purpose too, but GUI IDEs on multiple screens are on par at least.
Re: IDEs we had 30 years ago and lost (2023)
#166I'm interested in how these old IDEs were used during the transition from assembly to high level languages. It seems especially topical given the LLM integration into today's IDEs. Back then was it common to have a split or interleaved view of high level and assembly at the same time? I'm aware that you could do something like the following, but did IDEs help visualize in a unified UI?: $ cc -S program.c $ cat progra…
The Turbo Pascal version of this was even better, because you could do a whole block of asm instead of just a single line at a time. As I remember there were annoying limitations in the C version around labels and such. It was incredibly useful when writing performance oriented code at that time because it was very easy to write code that would outperform the compiler.
Re: IDEs we had 30 years ago and lost (2023)
#167Earlier quoted context omitted.
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.
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 Transi…
Yeah I agree. I think transient is one of the less appealing things about magit and isn't really very emacs-y. Also, you still have to memorise them anyway
Re: IDEs we had 30 years ago and lost (2023)
#168I'm interested in how these old IDEs were used during the transition from assembly to high level languages. It seems especially topical given the LLM integration into today's IDEs. Back then was it common to have a split or interleaved view of high level and assembly at the same time? I'm aware that you could do something like the following, but did IDEs help visualize in a unified UI?: $ cc -S program.c $ cat progra…
It was not very common to interleave assembly in MS-DOS IDEs. Assembler and its IDE were separate tools you paid for. But not unheard of.
You could "dump" your OBJ file for assembly.
Later C compilers got some better inline assembler support but this was towards the 32-bit era already.
Also Borland had its own compiler, linker and such as separate binaries you could run with a Makefile but you really never had to, as why would you when you can do that in the IDE in a single keypress.
Re: IDEs we had 30 years ago and lost (2023)
#169(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 frequen…
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.
Yeah. I used to work as a phone surveyor, the one you hate. Our software is a terminal connected to a mainframe. I got used to it after a few weeks and was very productive.
Costco Canada vision shops still use a terminal connected to an AS/400 machine as I snooped around last month.
Re: IDEs we had 30 years ago and lost (2023)
#170Nostalgia aside, those classic TUIs nailed responsiveness and cohesion. Modern setups can match features, but rarely that instant, synchronous feel. Emacs + Magit shows the power of text-first integration, yet JetBrains-style debuggers and glue still win for many. It’d be great to see a modern, fast, Borland‑like TUI with solid LSP and LLDB integration.