Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

Post reply on HN
Print view View original

71–80 of 607 posts

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

#71

Post by aleph_minus_one »

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.

> 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?

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

#72

Post by dapperdrake »

badsectoracula wrote: post #56
jeroenhd wrote: post #49

Earlier quoted context omitted.

One thing that's nearly impossible to replicate on modern systems is the extremely tight feedback loop these TUIs had. Keyboard latency was near non-existent while basic calculators these days will happily take a hundred milliseconds to process a key press. We don't need to go back to the 66MHz era, but it's embarrassing that programs running on a dozen computer cores all executing at several gigahertz feel less resp…

AFAIK Borland C++ (even on Windows) used to read the source from whatever editor buffers you had already in the IDE and since the compiler was part of the IDE, it cached various states in memory, which is why it was so fast (for a C/C++ compiler anyway - Delphi was much faster) even on slow hardware. Meanwhile Visual C++ (and modern IDEs) had you autosave the file to disk so the compiler, that was launched as a separ…

From what I remember researching it really js this.

Today, Python, Rlang, PHP, Java, and Lisp bring these features. But not C. Oh the irony.

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

#73

Post by bombcar »

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, so fast that they'd walk away while it was still loading screens, and eventually a printout would come out for the cage.

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

#74

Post by fragmede »

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…

The convenience is the point. Instead of having to go and find the file that lists a class's functions, an IDE can list them and you can just click on the one you want. As the author points out, LSPs do that function in the modern era, but the point is, it's useful. Doesn't have to be your cup of tea, but you should at least be able to see the point.

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

#75

Post by astatine »

Nostalgic! Turbo C was my preferred IDE over many years in the late 80s to mid 90s. What an amazing tool! Those key bindings, used in so many other IDEs since, are burned into muscle memory. Even after decades of not using them, they bring a smile back. CodeWarrior, the debugger, helped me understand what happens when you run a program more than literally anything else I read or was taught.

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

#77

Post by cmrdporcupine »

frou_dh wrote: post #63
cmrdporcupine wrote: post #45

Earlier quoted context omitted.

So, I have been using emacs on and off for 32 years at this point, and I my emacs all set up with eglot and rustic and magit and the like and it's great.. but I still find I just fall back to RustRover when doing development because (unlike some the classic TUI IDEs mentioned in TFA) it just never feels like it's fully glued together and it's always a bit fragile and I never remember how to do certain things -- even…

There is a good IDE-style debugger available for Emacs these days: https://github.com/svaante/dape Since it has no dependencies, I wouldn't be surprised if it gets merged into Emacs core at some point.

Thanks, I'll check it out. dap made me angrier and angrier the more I tried to configure and use it.
Post reply on HN