Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

281–290 of 607 posts

Re: IDEs we had 30 years ago and lost (2023)

#281
post #23

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.

> it just uses conventions he is not used to ...and everyone else, including everyone who is also using a GUI on Linux - even if they use the GUI version of Emacs.

Yeah, basically when they said that it should’ve begged the question “why is he not used to those conventions?” And the answer would be because the conventions it uses aren’t used by anything else (which means they can barely be called conventions), and makes no effort to adopt any conventions of the platform it’s running on even just to get you started.

Also, another user said it has a tutorial when opened which should teach the basics in “10 to 15 min” but I have a feeling I would need 0 minutes to learn the basics of turbo c++.

I get that there are diehard eMacs and vim fans and honestly I’m happy for them. But at the end of the day scientifically speaking ease of use is not JUST down to familiarity alone. You can objectively measure this stuff and some things are just harder to use than others even with preloaded info.

Re: IDEs we had 30 years ago and lost (2023)

#282

Earlier quoted context omitted.

[flagged]

People should also stop using terminal emulators. It is pretty silly to base software around ancient printing terminals. Everyone knows for a fact that only tech illiterates use a console instead of a GUI. Since all great devs use a GUI. Just a fact. Also, people should stop playing 2D games. It is pretty silly to base your entertainment on ancient technology when modern GPUs can render super-complex 3D scenes. And d…

Honestly hard to disagree with your first point even though it's sarcasm.

It's still quite easy to end up with a terminal you need to reset your way out of (eg with a misguided cat), not to mention annoying term mismatches when using remix/screen over SSH, across OSes, or (and this is self inflicted) in containers.

Re: IDEs we had 30 years ago and lost (2023)

#283

Nostalgia 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.

TextAdept, the most criminally-underhyped high-quality text editor that I know of, has supported LSP for quite some time now IIRC, and has (not just GUI versions but also) a first-class TUI version.

Re: IDEs we had 30 years ago and lost (2023)

#284

I'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…

I was writing game engines in Turbo C and assembler in 1988. I don't remember using inline assembler until the 90s. I just had all the graphics routines in a separate .asm file which was part of the build process and then linked in.

Re: IDEs we had 30 years ago and lost (2023)

#285
post #142

(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…

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)

I snickered a little because I know Visual Studio didn't have a version 1.0. Wikipedia identifies the first version as Visual Studio 97, which was at version 5.0. I remember before that there was "Microsoft Developer Studio 4.0" which came out around Windows 95, and could run on 95 or on NT 3.51. There was a Visual C++ 1.0 and a Visual Basic 1.0 released at different times. Meanwhile there were also the workhorses, Microsoft C and MASM. In those days, Borland and Watcom were real competitors to Microsoft for C and C++.

Re: IDEs we had 30 years ago and lost (2023)

#286
What amazes me every day is that I'm using literally the exact same GUI to build apps that I was over 30 years ago, with Visual Studio.

You could sit someone down from 1991 (Visual Basic 1.0) in front of Visual Studio 2026 and they would immediately know where everything is. (it still has BASIC in there too)

Re: IDEs we had 30 years ago and lost (2023)

#287

Earlier quoted context omitted.

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.

Costco still uses AS/400 company-wide for their inventory system I think

Interesting. Looks like it suits them perfectly. I wonder if the AS/400 is running in an emulator or on a real machine.

Re: IDEs we had 30 years ago and lost (2023)

#288

The arguments for using TUI IDEs are just very poor. Developers should not be relying on something as loaded with legacy bloat like the terminal, to do development. Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window. Really, TUIs are not very good. I get it, I use th…

I know, man.

Unless your window full of text is GPU-accelerated, tear-free and composited, with raytraced syntax highlighting and AI-powered antialiasing, what is even the point?

TUIs are great if your structure them around keyboard input. There's more of a learning curve, but people develop a muscle memory for them that lets them fly through operations. I think the utility of this is sorely underestimated and it makes me think of my poor mom, whose career came to an end as she struggled with the new mouse-driven, web-enabled custoner service software that replaced the old mainframe stuff.

The late 80s/early 90s trend of building GUI-like TUIs was really more to get users on board with the standard conventions of GUIs at a time when they weren't yet ubiquitous (among PC users). Unifying the UI paradigms across traditional DOS and Windows apps, with standard mouse interactions, standard pull-down menus, and standard keyboard shortcuts was a good thing at the time. Today it's less useful. Things like Free Pascal have UIs like this mainly for nostalgia and consistency with the thing they're substituting for (Turbo Pascal).

Re: IDEs we had 30 years ago and lost (2023)

#290

Earlier quoted context omitted.

[flagged]

People should also stop using terminal emulators. It is pretty silly to base software around ancient printing terminals. Everyone knows for a fact that only tech illiterates use a console instead of a GUI. Since all great devs use a GUI. Just a fact. Also, people should stop playing 2D games. It is pretty silly to base your entertainment on ancient technology when modern GPUs can render super-complex 3D scenes. And d…

Completely disingenuous. Stop the snark.

For UI there exists a straight up superior alternative, which keeps all of the benefits of the old solution. Neovim is just straight up better when used outside of a terminal emulator.

What is true for TUI vs. GUI is not true for CLI vs. GUI (or TUI for that matter) pretending the argument I made applies to the later is just dishonest. You can not replace CLI interfaces adequately by GUI or TUI interfaces, you can totally replace TUI Interfaces by GUI. See neovim as an example. It is superior software when used outside of the terminal.

Post reply on HN