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

431–440 of 607 posts

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

#431

Post by neutronicus »

kccqzy wrote: post #424
int_19h wrote: post #407

Earlier quoted context omitted.

> Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products. Borland switched to https://en.wikipedia.org/wiki/IBM_Common_User_Access shortcuts in the last few versions of their TUI - Ctrl+Ins, Shift+Ins, Shift+Del for clipboard, for example. Since Windows also supported them (and still does!) this actually made for a nice common system b…

And I only recently discovered that Ctrl+Ins and Shift+Ins worked in my Emacs despite me never configuring it; and it even works in the minibuffer. It also worked in a couple of terminal emulators I have tried on Linux. It's really more universal than one might think.

I use Shift+Insert constantly in Spacemacs since I can't use evil-mode "p" in the minibuffer

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

#432

Post by bryantnyc »

karmakaze wrote: post #148
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…

I wasn't paying attention to when 30 years ago actually was... So disappointing to expect a GUI Smalltalk System Browser and seeing DOS TUIs. And then delight recalling Turbo C/Pascal and MS C 4.0 with CodeView that even worked in 43 or 50 line modes.

Anyone else on here recall IBM VisualAge for Smalltalk -> VAST, or Cincom Smalltalk?

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

#433

Post by kickingvegas »

speed_spread wrote: post #379
dimitar wrote: 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's not about being arcane, it's about the lack of discoverability. Emacs and vi don't have (by default) affordances like a menu that enables a user to discover and learn the interface at their own pace. The learning curve is much smoother and allows for casual uses without having to pull a book each time.

FWIW, I started a project last year to build Transient menus for major Emacs modes called “Casual” to address discoverability. Interested readers can find more info about it here: https://kickingvegas.github.io/casual/

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

#434

Post by uniclaude »

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

[flagged]

SSH comes to mind.

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

#435

Post by eviks »

acuozzo wrote: post #339
cameldrv wrote: post #162

Earlier quoted context omitted.

Yes. Back in the DOS days, and even before, when people used actual terminals, there was a keystroke buffer. You'd see people who really knew the interface fly through tasks being multiple keystrokes ahead of the UI. Stuff would just flash onto the screen and disappear as it processed the input that was already in its buffer. It should be possible to implement this with modern frameworks, but it requires thought.

> 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

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

#436

Post by int_19h »

kccqzy wrote: post #424
int_19h wrote: post #407

Earlier quoted context omitted.

> Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products. Borland switched to https://en.wikipedia.org/wiki/IBM_Common_User_Access shortcuts in the last few versions of their TUI - Ctrl+Ins, Shift+Ins, Shift+Del for clipboard, for example. Since Windows also supported them (and still does!) this actually made for a nice common system b…

And I only recently discovered that Ctrl+Ins and Shift+Ins worked in my Emacs despite me never configuring it; and it even works in the minibuffer. It also worked in a couple of terminal emulators I have tried on Linux. It's really more universal than one might think.

It's unfortunate that the accidental standard also happened to be the one requiring the use of both hands. I think that's why Ctrl+X/C/V won in the end.

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

#437

Post by pjmlp »

anthk wrote: post #381
pjmlp wrote: post #267

Earlier quoted context omitted.

Agreed, we used TUIs because we couldn't afford anything better on MS-DOS, CP/M, 8 bit home computers. People on better systems like the Amiga and Atari were already past that.

Vim was born in Amiga and Amiga OS came with some Emacs clone.

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.

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

#438

Post by pjmlp »

eikenberry wrote: post #366
pjmlp wrote: post #353

Earlier quoted context omitted.

Xerox PARC, Atari, Amiga and many others had shells, without needing to live on a teletype world. It is only cross platform as long as it pretends to be a VT100.

It's not about needing to live in a teletype world, it is about how language/text is just a better interface for a general use computer. Computers primary feature is that they are programmable and an interface that allows you to take advantage of that is superior to one that doesn't. The programmable GUIs all failed to gain traction (smalltalk and like), that left the shell (and maybe spreadsheets) as the best UI for…

Great that Microsoft, Apple and Google are on the right path then, with AI voice controlled and gestures OSes.

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

#439

Post by tiku »

sheepscreek wrote: post #357

> Visual Basic was the pinnacle of graphics programming I am still shocked how no tool since has managed to come even close to VB. You could easily develop a moderately complex GUI application that felt snappy in an afternoon. C# with WinForms is the second closest to that. All other iterations since have not been designed with individual developers in mind, sadly. A powerful developing alternative to this paradigm c…

It was also very easy to build the visual aspect, tying it together was step 3 for me. It felt more like a mix of designing and powerpoint than programming in the beginning of a project. Very fast visual results to keep your momentum.

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

#440

Post by pkal »

sexyman48 wrote: post #427
pkal wrote: post #67

Earlier quoted context omitted.

Transient is the worst part about Magit IMO (the best parts are how you can prepare a commit to just include the right changes, or the functionality bound inside the transient menus that make complex operations such as fixups or rebases trivial). Transient UIs are consistently uncomfortable to work with, and could usually be replaced by just using a regular special-mode keymap in a custom buffer. The fact that Transi…

You say a lot of dumb ____ (but to be fair, I said a lot more when I was your age), but your disdain for transient is on the money. I'm a satisfied magit user, but transient is a blatant UX error and a confounded implementation. Some guy spends his 20% time hawking an entire suite around transient. No one cares.

I would love to hear what you disagree with :)
Post reply on HN