Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

31–40 of 607 posts

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

#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 it still exists, but I mean back from the 90s. I got a T-shirt from them at MacWorld '99 and still had it until not too long ago. High quality merch.

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

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

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

#34

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…

Terminals are full of legacy bloat, but TUIs don’t have to be. I don’t think Borland IDEs used ANSI.SYS.

How is graphical vim even different from TUI vim? At least Emacs can render images.

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

#35

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…

and yet zed is straight up slower than turbo c++

What? "Slower" how? And why would dev experience not matter more?

TUIs are bizarre legacy technology, which are full of dirty hacks to somewhat emulate features every other desktop has. Why would any developer use them, when superior alternatives, not based on this legacy technology, exist and freely available?

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

#36
post #5

Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded. I get the sense devs just don’t put a lot of effo…

A good article on minifying Rust binaries: https://github.com/johnthagen/min-sized-rust

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

#37
post #25

The knocks against Emacs feel unwarranted. It has plenty of colour; it has mouse support, even in the terminal, but not all terminals support it, so it's optional. It also runs in a GUI with, you know, image support and whatnot. You can rail against its defaults, but do not make misleading claims.

Also, the set of top-level things in the menu bar is not static. So even if you cannot directly interact with it for some reason, it gives you a hint that new things are possible in particular contexts. (Same goes for the 'tool-bar' that's distinct from the menu-bar)

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

#38
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.

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

#39

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)

Care to elaborate as to why they suck?

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

#40

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)

I think TUIs mostly suck for IDEs, but some tools like k9s or htop are nice.
Post reply on HN