Costco Canada vision shops still use a terminal connected to an AS/400 machine as I snooped around last month.

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.

I wish we'd made better correspondence between the GUI and the keys on the keyboard. For example, the ESC should always be top-left of the keyboard and every dialog box should have an escape that basically always does the same thing (go back/cancel) and is wired to the hardware key. Instead of drop-down menus at the top of the screen, we could have had pop up menus at the bottom of the screen that positionally correspond to the F1-F12 keys.

As the network ebbed and flowed, email too-often became unreadable without a GUI, and what was once a good time of learning things on usenet became browsing web forums instead. It sucked. (It still sucks.)

In the greater world, I saw it happen first at auto parts stores.

One day, the person behind the counter would key in make/model/year/engine and requested part in a blur of familiar keystrokes on a dumb terminal. It was very, very fast for someone who was skilled -- and still pretty quick for those who hadn't yet gotten the rhythm of it.

But then, seemingly the next day: The terminals were replaced by PCs with a web browser and a mouse. Rather than a predictable (repeatable!) series of keystrokes to enter to get things done, it was all tedious pointing, clicking, and scrolling.

It was slow. (And it's still slow today.)

For example, much of the time would be spend in a search dialog where you had a textbox on top and a grid with items right below. In the TUI version, all navigation was with arrow keys, and pressing down arrow in the textbox would move the focus to the first item on the grid. Similarly, if you used up arrow to scroll through the items in the grid all the way to the top, another press would move the cursor to the textbox. This was not the standard focus behavior for Windows apps, but it was very simple to wire up, and the users were quite happy with the new WinForms version in the end.

I use an iPhone and found a lot of usability issues. Some apps such as Stock are perhaps not too difficult to recreate in Obj-C. I’m kinda old timer so prefer Obj-C even that I don’t know anything about it.

https://en.wikipedia.org/wiki/IBM_i#Technology_Independent_M...

We probably still have a couple of PGM objects kicking around on our modern POWER hardware that were originally compiled on an old AS/400 system, but they run as native 64-bit POWER code like everything else on the machine.

The IBM midrange line gets a lot of undue disgust these days, it's not sexy by any means, sure, but just like anything running on modern day Z/OS you know that anything you write for it is going to continue to run decades down the line. Well, as long as you limit the amount of stuff you have running on 'modern' languages; because Java, Node, Python, Ruby, etc. are all going to need upgrades while anything written in 'native' languages (RPG, COBOL, C/C++, CL) compiles right down to MI and will keep working forever without changes.

The Machine Interface dates back to AS/400's predecessor, the System/38.

It's still updated by IBM and runs on POWER. It's just called "i" now.

I believe the naming went something like AS/400->iSeries->System i->System i5->i

Weird question, but I accidentally ended up with one of those in my hands that ran in probably non-blockbuster place from 1996 to 2000 :)

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.

So it didn't kill people, something else was that cause

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.

Three decades later I learn that there were utilities to make the keyboard buffer bigger. But, in those days before search engines, how was I to know?

so even 41 years seems to be in the scope.

I was expecting

- early projects that ended in Visual Studio 1.0 or NetBeans soon after, (2 to 9 years too early for them)

not

- "vim (1991) was not out yet" (not-a-quote, but my feeiling upon looking at ncurses instead of floating windows)

A few years before, it was very different - VisualAge and Rational Application Developer were the big names in the early 90s in "professional" IDEs. Interface Builder for university spin-outs or funky startups (and SunWorks / Forte Studio for the less-funky ones). CodeWarrior on the Mac (perhaps with THINK! hanging on too). I think Softbench was popular for scientific software, but I never actually saw it myself.

And then just a few years later, the rise of Java turned things upside down again and we got Jbuilder, Visual Cafe, & NetBeans as the beginning of yet another new wave. The Visual Studio suite really began to take off around then, too.

In short, the 90s were a time of huge change and the author seems to have missed most of it!

> 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 erogomics.

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.

You're also potentially over-specializing at one level while at the same time neglecting other levels.

Musicians run into this problem when, for example, they rely solely on muscle memory to make it through a performance. Throw enough stress and complicated music at them and they quickly buckle.

Meanwhile, a more seasoned performer remembers the exact fingers they used when drilling the measure after their mistake, what pitch is in the bass, what chord they are playing, what inversion that chord is in, the context of that chord in the greater harmonic progression, what section of the piece that harmonic progression is in, and so forth.

A friend of mine was able to improvise a different chord progression after a small mistake. He could do this because he knew where he was in the piece/section/chord progression and where he needed to go in the next measure.

In short, I'm fairly certain OP is talking about these levels of comprehension in computer programming. It's fine if someone is immensely comfortable in one IDE and grumpy in another. But it's not so fine if changing a shortcut reveals that they don't understand what a header file is.

Example Notepad versus Turbo C++ described on the article.

We used text terminals because that is what we could afford, and I gladly only start a terminal window when I have to.

It is only cross platform as long as it pretends to be a VT100.

Like OP, I remember the days when command line was all you had, and even then we used stuff like TUI file managers to mitigate the pain of it.

The main point is that for a general purpose computer the UI needs to integrate programming. Programming is how you use a computer. The shell (text) is currently the primary UI that inherently allows programming.

What kind-of UI does a modern phone present?

Perhaps I simply failed to see your definition of "a general purpose computer".

Please say what rules must be passed to meet your definition.

Exactly so. I am perfectly able to work entirely in a text/CLI world, and did for years. I don't becase I don't have to. I have better, richer alternative tools available to me now.

It was very odd to join Red Hat briefly in 2014 and meet passionate Vi advocates who were born after I tried Vi and discarded it as a horrible primitive editor.

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.

Having said that, some old TUIs were clearer and faster even on weaker hardware. This should be a lesson for us today. Color transitions and animated icons flying over the desktop are NOT what I need, but speed, clarity, and discoverability of more rarely used functionality are vital.

"INTRODUCTION TO THE SMALLTALK/V 286 ENVIRONMENT"

http://stephane.ducasse.free.fr/FreeBooks/SmalltalkVTutorial...

So much better than the TUI Smalltalk/V

>As for terminal IDEs, Neovim has never been more featureful, with LSPs and other plugins giving all the features this article discusses. I guess it isn't a mouse-driven TUI, so the author wouldn't be interested, but still.

Neovim instantly becomes a better piece of software if you use a GUI frontend. The terminal puts in arbitrary limitation and inconsistencies. Why anyone would use and interface paradigm which can not do color in a sane way is beyond me. Just use the GUI, it is better in every way.

Company I work for has a great browser based IDE but that’s something I would never setup and maintain for a personal project.

There's nothing wrong with graphical IDEs... or text user interfaces. Great developers use both. Low effort troll is low effort.

It is a total joke to call something which depends on how the underlying terminal emulator interprets specific ANSI escape sequences "multi platform".

There's another reason you don't mention.

Consistent UI.

TUI apps can (and in the Windows world usually do) use the same keyboard controls, derived from IBM CUA, as their GUI equivalents do.

This is why I use Tilde in the Linux shell: the same commands work in it as in Pluma or Leafpad or Mousepad or whatever: Ctrl+O opens a file, Ctrl-X/C/V to cut/copy/paste, Ctrl+N for new, etc.

Also, people should stop playing 2D games. It is pretty silly to base your entertainment on ancient technology when modern GPUs can render super-complex 3D scenes.

And don't make me start on people who still buy vinyl...

It's still quite easy to end up with a terminal you need to reset your way out of (eg with a misguided cat), not to mention annoying term mismatches when using remix/screen over SSH, across OSes, or (and this is self inflicted) in containers.

For UI there exists a straight up superior alternative, which keeps all of the benefits of the old solution. Neovim is just straight up better when used outside of a terminal emulator.

What is true for TUI vs. GUI is not true for CLI vs. GUI (or TUI for that matter) pretending the argument I made applies to the later is just dishonest. You can not replace CLI interfaces adequately by GUI or TUI interfaces, you can totally replace TUI Interfaces by GUI. See neovim as an example. It is superior software when used outside of the terminal.

This is not true at all. Terminal emulators are GUIs, the TUI is just another layer on top of that GUI. Using a TUI will always introduces additional latency, depending on the quality of the terminal emulator.

I do not know what GUIs or TUIs you are using, but my KDE Apps are all extremely snappy.

People on better systems like the Amiga and Atari were already past that.

As for where Vim was born, hardly matters, it was someone with UNIX culture background, that happened to own an Amiga.

As the sibling comment points out, MicroEmacs isn't really Emacs.

Also Emacs history is older than UNIX, and overlaps with Lisp Machines.

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.

Right now I can use the exact same software I use on my local machine. Can you give me any reason why I should consider anything else?

https://devblogs.microsoft.com/oldnewthing/20041130-00/?p=37...