I work for a reservation systems company (a GDS) that is used by thousands of travel agencies. Of course, since the system was created 30 years ago, you were only able to create reservation with a text-based interface at the time, with short commands, inconsistent and complex flows to do some non-trivial things etc. So it's despised by newcomers because learning curve is steep.

However, the company has been building new web-based solutions for a while, but all of them have so called "cryptic mode" where you can still directly input the commands, as it is order of magnitude faster, mandatory feature for experienced old-timer travel agents.

"inconsistent and complex flows to do some non-trivial things"

Note that's a characteristic of bad design, not a characteristic of CLIs, where constraining the UI to GUI, will merely result in a hard to use GUI, instead of a hard to use CLI.

Note that in an email or printed page I can provide any CLI walkthru and anyone can follow with minimal training ("Which key is the any key?"), but some purely graphical GUIs are impossible to discuss verbally, especially if badly designed (see above, and realize the badly designed ones are going to need the most help).

First, click on the icon that looks like a Rhinotia hemistictus nose, except its green. No, not that, thats more of a myrtle color, you want the really bright green one. OK, now if you see a screen that looks like a Type II Seyfert galaxy then you've clicked thru too far and need to click back. Oh no, there's no left arrow icon to go back, we outsourced development to save money and in the programmer's culture a left arrow is an obscene gesture indicating you mate with your sibling, so our discount software uses a thoracic vertebrae, superior side up, for its back icon, isn't that hilarious a "back bone" to go back oh those UX guys crack me up every time. Something thats one line at a shell interface that could have been cut and pasted in, can involve an hour of talking back and forth about a bad GUI.

> "inconsistent and complex flows to do some non-trivial things"

> Note that's a characteristic of bad design, not a characteristic of CLIs

That's a characteristic of hundreds of developers creating features over dozens of years, and those features interacting with each other in subtle ways.

In my experience, even in small projects and codebases things get notoriously inconsistent very fast. It's a hard thing to keep, as it requires conscious effort and most developers don't care that much. And once something goes to production (or far enough in non-regression phase), it's a game over.

On top of that, AFAIU, in legacy systems, storage space was severely limited. Hence PNRs had a rigid structure that was not very extensible. That's another fact due to which implementing new features in a backward-compatible way might have been cumbersome.

There's a reason most desktop support still rely on the command line in the windows start menu.

Altea Amadeus.

And all the three big GDS need to be thrown into a fire. "Oh you want to add a person to the PNR? Well tough luck! Not a use case we handle!"

You should see how Sabre handles email address with it's bizarre, limited, possibly 7bit character set from 1959.

In Sabre emails can be like 70 characters long. But periods count as two characters, as do underscores, and @ counts as four. I mean given the choice between period and cross of lorraine I know which I am choosing to include.

What character encoding do they use? ASCII is 7-bit, all those characters use 1 byte in ASCII, and of course email addresses were originally (and until recently?) restricted to ASCII.

Something weird:

https://sds.sabre.com/XTRANET_Access/sabre.htm

The @ is 0x2E20 in sabre hex

Lotus 1-2-3 (the spreadsheet before Excel) used to have a text-based interface that people could rattle through.

It was so popular, you can still bring up 1-2-3 text menu equivalents in Excel by typing "/".

There's certainly a trade-off between learning curve and long-term productivity. But the problem here is that vi/m gives shitty feedback, that's all. It should say "Press <ESC> and type :quit<Enter> to quit VIM" but it doesn't. Most first-time users lack a mental model of input modes, so they get stuck.

After pressing Ctrl-C a few times, the status bar says 'Type :quit<Enter> to exit Vim' for me. Not sure what else people try to exit vim.

There's always C-z, but that actually works.

I think your are mixing steep learning curve with having keyboard shortcuts (whether they are commands or combinations of keys). You can have keyboard based shortcuts with any UI. Actually a UI with no shortcut is probably a bad design in the first place. A steep learning curve just means it is hard to learn, i.e. non intuitive, non discoverable. These are not qualities.

I just hate programs that change patterns that are standard everywhere else. E.g. 99% of software uses control+c and control+v to do copy and pasting, so of course software that maps it to something totally different is going to be very frustrating. The same thing with vim using nonstandard way of quitting.

Discoverability is another problem. You can have weird keyboard commands, but make it possible to find them without searching stack overflow. I miss when applications had a big bar at the top of all the commands you could do and their keyboard shortcuts. I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place? Or apple phones have a bunch of gestures that are useful, but no one knows about because you can't discover them.

Approximately 0% of terminal programs use control-c as copy. Conventions depend on context.

"Control-C sends SIGINT" has been a standard for longer than "Control-C means copy".

I'm well aware of that and the historical reasons that it's the case. I'm just using it as an example of breaking well established patterns that screw new users.

^C as copy is an example of breaking well established patterns that screw new users. Its THE canonical example in fact.

^C is SIGINT. ⌘C is copy.

I blame Microsoft.

Didn't Ms"S use to use CTRL-Ins or similar?

The name that you want to look up is Common User Access.

Well TIL, thanks! Interesting to know the history.

(I still have a few Windows apps we use at work that use these standards; good to know they actually were a standard.)

I really don't care who is responsible or which came first. I'm only pointing out the inconsistency and the problems it causes.

Don't worry, in few years new bindings will be familiar to new people straight from their birth date. Then they will complain about changes and you'll tell them that changes were made long before.

Shortly after the introduction of the first generation of brain-computer interfaces: "Why do I have to think of Ctrl-C to copy text in this program? All the other programs have me think of a banana to copy a selection!"

> I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place?

Copy and paste are also in the right-click menu, and the keyboard shortcuts are shown there.

Vi predates the Ctrl+C.X.V convention. Shame on all those Windows apps for not using the Esc key properly.

I hate VI not defaulting to wasd for movement like every other single piece of software I used growing up... (e.g. Quake, Marathon...) Ha ha ha. (Or should my games have used hjkl)?

As I recall, both Quake and Marathon defaulted to arrow keys for movement. Half-Life was the first time I encountered WASD out-of-the-box.

> (Or should my games have used hjkl)?

I still play a game that does...

> The same thing with vim using nonstandard way of quitting.

How do you quit man? How do you quit less?

'q' to quit is pretty standard in the TUI world.

I tried it and typing q does not seem to exit the program. Nothing I tried worked and I had to exit the whole terminal.

Well it's not quite that simple because it's more complicated than those tools. Once you are in ex mode ':' though it uses the standard exit key.

As for if you stuck in insert mode, this is more akin to when you have text highlighted in a GUI editor, the shortcuts change because you're in a different mode.

Remember all editors have modes, vim is just a bit more in your face with them.

You have to type :q to quit. : Is the command mode.

Missing one step. <esc>:q

Actually, the missing step is the <cr> at the end.

The <esc> at the beginning is only necessary if you've already got into insert mode. That said, it'll not do any harm.

So intuitive.

q is only quit when run as a command. In normal mode, it's record.

just run vimtutor

I worked on Z/OS mainframes for a couple of years and the point-and-shoot interface is indeed very efficient, once you've learned to use it.

The only thing I remember being really annoyed with was that there was no way (or no way I managed to find) to select all the text in a line in one go. The same was true for the editor (EZY). I kept pressing Ctrl + V to do a block-select and pasted all sorts of gibberish all over the place. Apparently, there are no line endings in text fields so it's not possible to get something like block-selection working.

But that was about the only thing that sucked from my point of view and I grew up with GUIs and touch-interfaces, like everyone else in my generation.

A bit late to the convo here, but one of the things that really impressed me about the Bloomberg (my employer) Terminal is how they manage this old user vs. new user problem well.

The terminal looks like this now: https://www2.le.ac.uk/departments/economics/images/bloomberg...

You can still do everything with the same keyboard shortcuts that have worked for 30+ years (pretty much everything with a number in front of it), and the layout of the screens generally don't change. But now everything on the mostly text-based view is clickable as well--everywhere you see a number you can click with a mouse.

Additional shortcuts are hidden behind menus, like "Settings" in the photo. But if you know the shortcut, no need to look at "Settings" first (which itself can be opened by typing 97 or clicking it).

> My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design.

It does if the app is aimed at companies with high turnover where said learning curve poses a continual problem for users.

If there is high turn over then the length of the learning curve is more important than the shape of it. Let's say there are two apps each with an employee starting, one requires two full days of training to be 90% proficient, the other allows for an instant start with a more gradual learning curve.

After 30 days of employment the first has spent 28 days at 90% efficiency, the other has had 7 days at 60% efficiency, 7, days at 80% efficiency etc.

A gradual learning curve could be much worse for companies with a high turn over.

Absolutely true.