Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

531–540 of 607 posts

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

#531
post #437

Earlier quoted context omitted.

I surely don't remember such clone. As for where Vim was born, hardly matters, it was someone with UNIX culture background, that happened to own an Amiga.

> I surely don't remember such clone. I think they mean MicroEmacs. Despite its name, it was not Emacs, but it had Emacs-like keyboard shortcuts, multiple buffers, and macros, which was quite neat for a free 1986 application on a home computer.

I guess that is it, thank for the memory refresher, and to be more precise, MEmacs.

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

#532

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…

This is just a bundle of your opinions -- to which you're entitled, even if they're totally wrong -- but downthread I see you attempt to defend them and claim they are objective fact, which is simply ridiculous.

TUIs are a superb tool. They were when they were first standardised in late-tera DOS apps in the late 1980s and early 1990s, and they still have a place today.

Here are some primary reasons you have not considered in your rant:

* UI standards and design

TUIs bring the sensible, designed-by-experts model of UI construction and human-computer interface from the world of GUIs into text-only environments such as the terminal, remote SSH connections, and so on.

For example, they let one set options using a form represented in dialog box, by Tabbing back and forth and selecting with Space or entering values, without trying to compose vast cryptic command lines.

This is not just me; this is the stuff of jokes. This is objective and repeatable.

https://xkcd.com/1168/

https://xkcd.com/1597/

* Harmonious design

A well-done TUI lets users use the same familiar UI both in a GUI and at the console. This is the actively beneficial flipside of the trivial cosmetics you are advocating: you praise a text-mode app implemented in a GUI because it can do more. That is a poor deal; a ground-up native GUI app can do much more still.

But TUIs bring the advantages of familiarity with GUIs to situations where a GUI is unavailable.

* Common UI

The apps you cite as positive examples are markedly poor at following industry-standard UI conventions, which suggests to me that you are ignorant that there are industry standard UI conventions. Perhaps you are too young. That is no crime, but it does not mean I must forgive ignorance.

Nonetheless, they exist, and hundreds of millions of people use them.

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

TUIs allow familiar UIs to be used even when a GUI or graphics at all are unavailable.

TUIs are not just about menus; they also define a whole set of hotkeys and so on which allow skilled users to navigate without a pointing device.

* Disabilities and inaccessibility

Presumably you are young and able-bodied. Many are not.

GUIs with good keyboard controls are entirely navigable by blind or partially-sighted users who cannot use pointing devices. They are also useful for those with motor disabilities that preclude pointing and clicking.

Millions use these, not from choice, from need.

But because those tools are there, that means that they can also use TUI apps which share the UI.

And the fact that this common UI exists for keyboard warriors like myself, who actively prefer a keyboard-centric UI, means that the benefits of a11y carry across and remain benefits for people who do not need a11y assistance.

=====

That's 4 reasons, intertwined, that you showed no sign of having considered. IMHO any 1 of the 4 is compelling on its own but combined any 2 would be inescapable and all of them together, for me, completely rebut and refute your argument.

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

#534

We didn't lose all of them though. I know at least mcedit and eFTE are still kicking. And there's some new ones that pay tribute to the interface style such as https://github.com/istoph/editor

As above -- also Tilde which in my testing is much superior to either mcedit or eFTE.

https://github.com/gphalkes/tilde

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

#535
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…

A hundred years ago I found something called XWPE and managed to build it for sco osr5, and then pretty much never used it for real. (That doesn't imply I went with VS or similar fat ide, just that I didn't end up using xwpe for real. I tried code::blocks for a while but mostly just use geany or a plain editor.)

Try Tilde.

https://github.com/gphalkes/tilde

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

#536
post #435

Earlier quoted context omitted.

> You'd see people who really knew the interface fly through tasks being multiple keystrokes ahead of the UI. I remember. This, unfortunately, killed people: Therac-25. Granted, the underlying cause was a race condition, but the trigger was the flying fingers of experts typing ahead, unknowingly having been trained to rely on the hardware interlock present in older models.

> This, unfortunately, killed people: Therac-25. Granted, the underlying cause was a race condition So it didn't kill people, something else was that cause

I'm not trying to shift blame to the operators here, but in the absence of flying fingers, nobody would have died. Many, many, people received the right treatment in the Therac-25 machine.

Also, the author of the buggy software had no idea it would be used to operate a machine without a hardware interlock as, AFAIR, it was not modified prior to being used with the Therac-25 model.

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

#537

Lotta focus on TurboPascal vs Emacs or whatnot at the console level, but you couldn't give TurboPascal to a complete newbie any more than you could give them IntelliJ. The mouse is an advantage here, not a disadvantage.

The mouse worked fine in the Turbo IDEs.

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

#539

Earlier quoted context omitted.

Thank you for your helpful reply. I'm afraid I don't have enough familiarity with emacs to quite follow your explanation - I didn't actually write the bit of emacs-speak in my previous message, and I don't know what its terms mean. I just asked ChatGPT to invent something one emacs user might plausibly say to another! It has always sounded like emacs is extraordinarily powerful and configurable, and that must be grea…

I get you. Emacs is one software that you must invest some time to get the famous ROI. The promise is one unified interface for all the tools you may need (editor, tasks runner, shell, spellchecking, file manager,...). But the learning curve is there, although not as steep as some would make it appear. One of my major motivation for putting in the time is that Emacs is very stable. You can coast for decades on a conf…

Well, that's ironic. I actually do spend all day, every work day, in a piece of software which unifies most of the tools I need - editor, file manager, make console, find/grep frontend, etc. It's as stable as can be, since I'm the only person who maintains or even uses it, and it's as simple as can be, since I don't bother to write features in unless I really want them.

I've always supposed that emacs was for people with inscrutably complex text-editing needs, far beyond the bounds of my "nano is plenty" imagination, but if my cozy little coding environment is the kind of thing people are doing with emacs, I can understand why they would like that.

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

#540

Earlier quoted context omitted.

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?

i'm talking about turbo c++ of the 90s. it was a completely integrated experience. no screen switching was key. everything contained in one app. worth all the nostalgia but you kind of had to be there! and yep it was faster than zed.
Post reply on HN