IDEs we had 30 years ago and lost (2023) • Hacker News Board

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

#101

Post by cess11 » Sat, Oct 18, 2025, 2:33 PM UTC

I don't know, all of those are pretty similar to me.

I'd like to be able to develop in other languages the way I do when I dabble in Pharo, i.e. mostly windows and widgets and dialogs that abstract away boilerplate, file and directory management, and allows me to relatively easily extend the environment when I feel like it.

Instead I tend to complement the editor or IDE with a rather large set of Linux and Unix programs in terminal emulators. It's not nice or easy to teach, but nicer than trying to figure out whatever module protocol used by the editor. Perhaps I could have stayed with Emacs and been content, but when I arrived at this methodology Emacs was still single threaded and quite sluggish in comparison.

I'm hoping Glamorous Toolkit might be the thing that eventually grows into what I'd like to have.

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

#102

Post by andsoitis » Sat, Oct 18, 2025, 2:33 PM UTC

dardeaup wrote: post #95

andsoitis wrote: post #83

Delphi - fantastic, modern RAD IDE. Borland heritage. Can build native apps for Windows, Linux, macOS, iOS, and Android. https://www.embarcadero.com/products/delphi

Delphi is still very impressive. However, they missed out on a much greater opportunity. Part of Delphi's crown jewels is VCL which can only be used on Windows. If you use Delphi for an OS other than Windows you have to use FireMonkey/FMX. Lazarus has LCL which is VERY similar to VCL, but LCL on Lazarus is not limited to Windows. One can write a LCL application and it works the same on Windows, macOS, and Linux. If D…

Don’t disagree that VCL across all the platforms would be a game changer.

However, the quality and reliability of the Delphi experience together with mobile support overcome the VCL/FMX trade off in my books.

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

#103

Post by esafak » Sat, Oct 18, 2025, 2:34 PM UTC

bombcar wrote: post #73

mkovach wrote: post #32

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…

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…

The old TUIs were faster yet I still prefer IntelliJ; it's fast enough and much more powerful.

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

#104

Post by dardeaup » Sat, Oct 18, 2025, 2:34 PM UTC

constantcrying wrote: post #14

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'd bet you never seriously used Borland's Turbo Pascal for DOS versions 5.5 or 6.0. That IDE was extremely FAST. A lot of really good software was written in it back in the day (pre-internet).

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

#105

Post by tjpnz » Sat, Oct 18, 2025, 2:35 PM UTC

guerrilla wrote: post #31

I'm going to get punished for saying this, but I don't really see the point of IDEs when you have things like vim, Makefiles and bash. It just seems like more things to go wrong. I used Eclipse while I was doing Java development for a while and it had some conveniences but for the most part I just see it as one more thing that can go wrong and get in my way. Anyway, does anyone remember Metrowerks CodeWarrior? I see…

I do like the "quietness" of vim. With a minimal configuration I've replaced most of the conveniences I enjoyed with PyCharm and VSCode, but without the constant notification spam and weird virtualenv configuration issues I previously had switching between projects.

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

#106

Post by layer8 » Sat, Oct 18, 2025, 2:36 PM UTC

floam wrote: post #70

PaulHoule wrote: post #8

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

Damn that actually sounds superior. How did changing the size work?

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.

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

#107

Post by 1313ed01 » Sat, Oct 18, 2025, 2:36 PM UTC

pragmatic wrote: post #33

TUIs sucked and they still suck. Programmers are trying to bring them back bc nostalgia I guess? I floated the idea of TUIs to our data engineering team and got very negative responses. (My nostalgia for undergrad turbo pascal TUI I guess lol)

They are undeniably programmer-friendly though, no matter how hated by users. Much easier to do things when you are limited to just a grid of fixed size characters rather than the bizarre complexities of modern GUIs.

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

#108

Post by TinkersW » Sat, Oct 18, 2025, 2:37 PM UTC

api wrote: post #26

AlexeyBrin wrote: post #11

Earlier quoted context omitted.

Mostly because of static linking. C and C++ don't put every library they need in the binary by default. The advantage is that a pure Go or Rust binary just works (most of the time) when copied from one machine to another, you don't have to care about installing other libraries.

That’s a great point. Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible. The only other kinds of systems that can optimize this way are higher level JIT runtimes like the JVM and CLR. These can treat all code in the VM as a unit and optimize across everything.

  C++ has had whole program optimization since forever. And you can use static linking if you want, the same as Rust.

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

#109

Post by skydhash » Sat, Oct 18, 2025, 2:38 PM UTC

layer8 wrote: post #97

dimitar wrote: 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.

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.

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.

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

#110

Post by 3836293648 » Sat, Oct 18, 2025, 2:38 PM UTC

aleph_minus_one wrote: post #71

api wrote: post #26

Earlier quoted context omitted.

That’s a great point. Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible. The only other kinds of systems that can optimize this way are higher level JIT runtimes like the JVM and CLR. These can treat all code in the VM as a unit and optimize across everything.

> Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible. I get why this might lead to big intermediate files, but why do the final binaries get so big?

Rust binaries + all their dynamic libraries are the same size as C++ binaries + their linked libraries (when stripped, this isn't default in Rust)

The main issue is that Rust binaries typically only link to libc whereas C++ binaries link to everthing under the sun, making the actual executable look tiny because that's not where most of the code lives.