Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

351–360 of 607 posts

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

#351

Earlier quoted context omitted.

Magit is mind blowing. How did the magit guy or people even come up with the data model? Always had the feeling that it went beyond the git data model. And git porcelain is just a pile of shards.

For reference, I did use Magit for my short stint with Emacs (and then Spacemacs/Doom Emacs). I've always been more into Vim. I tried the Atom editor several years ago with lots of Vim emulation and quite a bit of customization - one of those being a Magit clone. I moved to NeoVim many years ago and have been using NeoGit (a supposed Magit clone) the entire time. It's good but I'm missing the "mind blowing" part. I'd…

I found Neogit quite buggy. Not even in the same league as Magit.

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

#352

Earlier quoted context omitted.

> it just uses conventions he is not used to ...and everyone else, including everyone who is also using a GUI on Linux - even if they use the GUI version of Emacs.

Yeah, basically when they said that it should’ve begged the question “why is he not used to those conventions?” And the answer would be because the conventions it uses aren’t used by anything else (which means they can barely be called conventions), and makes no effort to adopt any conventions of the platform it’s running on even just to get you started. Also, another user said it has a tutorial when opened which sho…

> I have a feeling I would need 0 minutes to learn the basics of turbo c++.

Well, Turbo C++ (at least the one in the article) does use common conventions but those were conventions of 1992 :-P. So Copy is Ctrl+Ins, Paste is Shift+Ins, save is F2, open is F3, etc. Some stuff are similar to modern editing like Shift+motion to select, F1 for help, F10 to activate the menu bar, etc. And all shortcut keys are displayed on the menu bar commands so it is easy to learn them (some of the more intricate editor shortcut keys are not displayed in the menus, but are mentioned in the help you get if you press F1 with an editor window active).

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

#353
post #255

Earlier quoted context omitted.

As someone that started when only rich people could afford GUIs, I don't understand what is killer app about it. We used text terminals because that is what we could afford, and I gladly only start a terminal window when I have to.

The killer thing about it is that it is a gateway to the shell, all the command line tooling and the best cross-platform UI.

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.

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

#354
post #252

Earlier quoted context omitted.

Failure of Linux Desktop you mean. RDP works great and GUI tooling for Windows and macOS is quite comparable to using VB, Delphi, Smalltalk like experiences.

RDP works great on Linux as well. The problem isn't remote access, it is lack of good cross platform GUIs. There is a reason browsers are dominating the UI space and TUIs are popular.

Yeah, laziness, we had plenty or cross platform GUIs in the 1990's.

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

#356

I'm interested in how these old IDEs were used during the transition from assembly to high level languages. It seems especially topical given the LLM integration into today's IDEs. Back then was it common to have a split or interleaved view of high level and assembly at the same time? I'm aware that you could do something like the following, but did IDEs help visualize in a unified UI?: $ cc -S program.c $ cat progra…

The Turbo Pascal version of this was even better, because you could do a whole block of asm instead of just a single line at a time. As I remember there were annoying limitations in the C version around labels and such. It was incredibly useful when writing performance oriented code at that time because it was very easy to write code that would outperform the compiler.

I'm pretty sure you could do asm blocks in Turbo C using brackets, e.g. asm { ... }, though it might have been a Turbo C++ thing (i never really used plain TC much).

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

#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 could be what I’m calling speech/voice driven development (SDD or VDD). It takes some pain of typing so much away - makes interactions with AI feel a bit more natural. Like talking to a colleague. But for it to really work well, AI models will need to become even faster.

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

#358
post #252

I think these modern TUIs are a testament to the general failure of modern GUIs. It's not like they're particularly easier to write these. But since there's no remote GUI option, much less a portable remote GUI option, particularly one that's not just a video of an entire desktop, we're stuck with these. WHo wants to fire up an entire desktop to get open a simple utility app? Obviously the Web satisfies much of the d…

Failure of Linux Desktop you mean. RDP works great and GUI tooling for Windows and macOS is quite comparable to using VB, Delphi, Smalltalk like experiences.

There are no failures for Linux Desktop; this can never be the meaning. I say this with humor in mind.

Requiring me to have a cloud account to format my machine (mac) and requiring me to have a cloud account on only pre-authorized hardware (Windows 11), only to open up Notepad and see they slapped AI inside of it; now that is quite comparable to me slapping Linux on it.

Just sayin'

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

#359

Earlier quoted context omitted.

Yeah. I used to work as a phone surveyor, the one you hate. Our software is a terminal connected to a mainframe. I got used to it after a few weeks and was very productive. Costco Canada vision shops still use a terminal connected to an AS/400 machine as I snooped around last month.

In the late 90s I was required to slowly replace dumb terminals with PCs. One of the older ladies taking phone orders was most put out by this, understandably. She was lightning fast on that terminal. She'd never used a PC (I hit on the idea of using solitaire to learn to use a mouse, which worked amazingly well), and was never able to get to the same speed with one as she'd done on her dumb terminal. It's hard to be…

While I agree that dedicated devices can be more efficient than Windows-style user interfaces, and even more so than browser-based user interfaces, many people don't use those modern interfaces in efficient ways.

I have observed countless times how many people fill in a field, than move their hand to the mouse to move the focus to the next field or button, than move their hand back to the keyboard, instead of just pressing tab to move the focus. It's painful to watch. Knowing just a few keyboard shortcuts makes filling in forms so much faster.

Things are getting worse, unfortunately. Modern user interfaces, especially in web interfaces, are made by people who have no idea about those efficient ways of using them, and are starting to make it more and more difficult to use any other method than keyboard -> mouse -> keyboard -> mouse -> ... . Tab and shift-tab often don't work, or don't work right. You can't expand comboboxes with F4, only the mouse. You can't type dates, but have to painstakingly select all the parts in inefficient pickers. You can't toggle options with the spacebar. You can't commit with enter or cancel with esc.

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

#360
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 is however fully self-documented and interactive. Unfortunately not true. I've fired up emacs once or twice, and couldn't even figure out how to save a document because it didn't show me how to do that. It might be more documented than vi (but that bar is *on the floor, vi has one of the most discovery-hostile user interfaces ever made), but it's not self-documented enough to just pick up and use with no instruc…

vi is documented

Problem is most people start it the first time by providing a text file instead of firing it on its own and be greeted by the tutorial. I guess that is because they are blindly following another tutorial instead of trying to understand what they are doing.

My opinion is that "self documentation", "Getting started" pages and "tutorials" is a disease. People would actually get up to speed quicker by reading real manuals instead. They are just lured into thinking they will learn faster with tutorials because they get their first concrete results quicker but at this stage the harsh reality is thay they still usually don't know anything.

First time I used vi, I just had my operating system manual on my desk and I quickly learned to open man pages in a separate tty.

Post reply on HN