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

1–10 of 607 posts

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

#2

Post by sph »

Now that CLI tools are in fashion again... has nobody thought to recreate a modern version of Turbo C++/Pascal?

I know there's Emacs and vim, but they're far too programmable and bloated compared to the elegance of TC++, which did one job, and one job only, very well. Also, despite being an Emacs power user at this point, it's never going to be as ergonomic and well thought out with its arcane chords, while TC++ conveniently shows all possible keybinds throughout its UI.

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

#4

Post by AlexeyBrin »

sph wrote: post #2

Now that CLI tools are in fashion again... has nobody thought to recreate a modern version of Turbo C++/Pascal? I know there's Emacs and vim, but they're far too programmable and bloated compared to the elegance of TC++, which did one job, and one job only, very well. Also, despite being an Emacs power user at this point, it's never going to be as ergonomic and well thought out with its arcane chords, while TC++ conv…

FreePascal has a text mode IDE similar to the old Turbo Pascal 7.0 that you can use in a Terminal. So you can use a modern Pascal compiler from it.

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

#5

Post by api »

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 effort into stripping dead code and data since “storage is cheap” but it shows next to C or even C++ programs that are a fraction of the size.

I see nothing about Rust’s safety or type system that should result in chonky binaries. All that gets turned into LLVM IR just like C or C++.

Go ships a runtime so that explains some, but not all, of its bloat.

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

#6

Post by coolcoder613 »

sph wrote: post #2

Now that CLI tools are in fashion again... has nobody thought to recreate a modern version of Turbo C++/Pascal? I know there's Emacs and vim, but they're far too programmable and bloated compared to the elegance of TC++, which did one job, and one job only, very well. Also, despite being an Emacs power user at this point, it's never going to be as ergonomic and well thought out with its arcane chords, while TC++ conv…

Have you seen tvision[0] and turbo[1]?

[0] https://github.com/magiblot/tvision [1] https://github.com/magiblot/turbo

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

#7

Post by jfengel »

I used most of these and they weren't worth it. They didn't do enough to justify being locked in to the tool. The debuggers were too, uh, buggy. Command line tools were more flexible.

They finally got good enough in the late 90s. I think it helped that computers finally had enough memory to run both the editor and the program itself.

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

#8

Post by PaulHoule »

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 that use up even more bytes.

I first used emacs on terminals that were hooked to Sun workstations and you were either going to use a serial terminal which was very slow, or the terminal emulator on the Sun which was a GUI program that had to do a lot of work to draw the characters into the bitmap. So that’s your reason TUIs went away.

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

#9

Post by kranke155 »

api wrote: 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…

What binaries are a good example of this?
Post reply on HN