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

201–210 of 607 posts

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

#201

Post by geophile »

Turbo Pascal was completely amazing. I remember resisting it for a long time, because IIRC it implemented non-standard Pascal. But the competitive tools were less powerful and far more expensive, (e.g. the Microsoft tools). And then I tried it, and was completely blown away. I no longer cared about the non-standard stuff. I had a fast intuitive IDE running on my original IBM PC.

As for modern IDEs, Intellij has been orders of magnitude better than any competition for more than 25 years (I think). I have stayed away from Microsoft products for a very long time, so I can't comment on VSCode and its predecessors. The main competition I remember was Eclipse, which I always found to be sluggish, unintuitive, and buggy. The fact that it wasn't even mentioned in this article is telling.

JetBrains, the company that created Intellij (and then PyCharm, CLion and many others) is one of those extremely rare companies that defined a mission, has stuck to it, and excelled at it for many years, and has not strayed from the path, or compromised, or sold out. It is so impressive to me that they maintain this high level of excellence as they support a vast and ever-growing collection of languages, coding standards and styles, and tools.

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

#202

Post by tangotaylor »

Having TUIs available for remote administration is an excellent point. I frequently spin up nmtui on machines with NetworkManager because I’m used to Ubuntu’s network settings GUI and I haven’t bothered to learn enough nmcli.

(“real” deployments would use systemd-networkd and config files but for simple things…who cares)

No matter how good computers and networking get, text-based tools always seem to win for remote administration. I’ve tried forwarding X servers, mounting remote file systems with sshfs, vscode’s remote features, VNC, RDP, but I always seem to revert back to just tmux and TUI tools.

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

#203

Post by rkomorn »

prinny_ wrote: post #200
constantcrying wrote: post #176

Earlier quoted context omitted.

Neovim instantly becomes a superior piece of software if you use any of the GUI frontends. If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems. The terminal version is most likely slower as well as you now also have the entire legacy terminal overhead. >I think what TUIs get right is that they are optimized for use by the keyboard. Neovim is jus…

> If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems I use neovim like that and the selling point for me is that it's 1 less program that I have to install and learn with the added (crucial) benefit that it doesn't update on its own, changing UI and setting that I was used to.

> it's 1 less program that I have to install

It ships with your OS?

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

#205

Post by SoftTalker »

Lapel2742 wrote: post #53

> “In my house”, we used something called SideKick Plus (1984), which wasn’t really a code editor: it was more of a Personal Information Management (PIM) system with a built-in notepad. Finally! Someone who still remembers the best software ever written. I looooved Sidekick and we used it throughout our small company. It's so long ago. I remember only parts of it now but it was such a useful tool.

The reason IDEs blossomed on DOS was because there was no multitasking. On unix/linux, even on a "dumb" tty with no GUI, you could hit CRTL-Z and your editor would go into the background and you'd be at a shell where you could run make or gdb or manage files. Then type 'fg' and your editor would be back exactly as you left it.

IDEs do all that in one huge program because if you exited your editor to run the compiler or run your program, when you went back to the editor it was starting up cold again.

TSR programs like Sidekick avoided some of this but were a poor substutute for real multitasking.

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

#206

Post by manithree »

The Borland Turbos had a much bigger market impact, but I was blown away by the Zortech C++ IDE in 1988. I don't remember why any more, but I was very dismissive of other TUI IDEs of the day after using Zortech. Even in the early 1990's when I was professionally using PWB (Programmer's Waste Basket) I still felt Zortech's IDE was superior.

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

#207

Post by jeroenhd »

constantcrying wrote: post #115
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…

>One thing that's nearly impossible to replicate on modern systems is the extremely tight feedback loop these TUIs Why? Yes, VSCode is slow. But Zed and many neovim GUIs are extremely responsive. Why would achieving that even be impossible or even that hard? You "just" need software which is fast enough to render the correct output the frame after the input. In an age where gaming is already extremely latency sensiti…

I'm not sure if you know what "terminal" means. I'm not talking about terminal emulators (the "terminal" program on macOS/Linux/Android/etc.) but actual, real terminals. The "terminal" is a text mode rendering mechanism built into computers of the terminal era. The closest modern operating systems come to it is the terminal-like environment you can get on Linux or the *BSDs by disabling the GUI, but even those merely emulate text mode, they still contain the stacks upon stacks of timers and necessary to process input peripherals.

The problem is the entire software stack between the keyboard and the display. From USB polling to driver loops and GPU callbacks, the entire software stack has become incredibly asynchronous, making it trivial for computers to miss a frame boundary. Compared to DOS or similar environments, where applications basically took control over the entire CPU and whatever peripherals it knew to access, there are millions of small points where inefficiencies can creep in. Compare that to the hardware interrupts and basic processor I/O earlier generations of computers used, where entered keys were in a CPU buffer before the operating system even knew what was happening.

VSCode isn't even that slow, really. I don't find it to be any slower than Zed, for instance. Given the technology stack underneath VSCode, that's an impressive feat by the Microsoft programmers. But the kind of performance TUI programs of yore got for free just isn't available to user space applications anymore without digging into low-level input APIs and writing custom GPU shaders.

In small part, CRTs running at 70Hz or 85Hz back in the mid-80s, as well as the much smoother display output of CRTs versus even modern LCDs, made for a much better typing experience.

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

#208

Post by tern »

I think what people miss about bloat, and about what's changed with software over the years, is that a vast variety of niche use-cases are now supported. Software runs on dozens of different systems, every aspect is customizable and programmable, and thousands of different programming languages and approaches are supported.

To give a random example, I use Neovim with SuperCollider, and music programming language. This involves launching a runtime, sending text to the runtime, which in turn sends commands to a server. The server generates a log, which is piped back into a Neovim buffer. There are all sorts of quirks to getting this functional, and it's a somewhat different workflow from any traditional programming model.

I'm not sure there's an easy solution to keeping things simple while also supporting the unimaginable variety of personalities, skill-levels, environments, and tasks people get up to. I do, however, think it's worth continued imagination and effort.

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

#210

Post by EbEsacAig »

heresie-dabord wrote: post #159
CGamesPlay wrote: post #125

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

When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…

> When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment.

I think you are wrong.

https://en.wikipedia.org/wiki/Muscle_memory

Being extremely good at something increases the gap between said something and everything else. That doesn't mean being extremely good at the first thing is "over-specialization to detriment". If someone is equally mediocre at everything, they have no such gap, so no "over-specialization to detriment"; but is that really worth desiring? I think not.

Post reply on HN