But is it really more inconsistent than UI interfaces? It feels like every graphical coding tool I use these days, have the menu in a different corner. Some requires me to use a web browser, others run in heavy virtual machines that take an hour to start up.

Is's one thing to keep a consistant UI within your own application, but doing it across a hundred different ones is something I have still to see, in the graphical world as well as the text based.

That is true; and it is generally considered a failure of UI design, especially if these differences show up side-by-side in the same system. That graphical coding tools have these problems is in part my point - many hops up this chain, pavlov bemoaned the lack of GUI coding tools, and I pointed out whether a UI is good and whether it's text-based are orthogonal properties

As an example of how it's possible to make a consistent UI among diverse applications: both Android and iOS have had a lot of effort put in to make app developers converge on consistent idioms; early Android did not do this, and was widely panned for it in the UI design community. The way iOS did this from the start, and Android does it now, is by having the "owner" of the system publish libraries that implement these standard UI idioms.

In the Unix and command-line world this has mostly been the province of GNU, which published the widely (but sadly, still not universally) used getopt_long, which was a big step forward for usability by imposing some level of uniformity on at least the syntax level of command-line args; more universal adoption of them would be great. There's still a problem of word choice and abbreviation choice, which hasn't yet been standardized across commands (quick, which of these recurses onto subdirectories! grep -R, grep -r, sed -r, cp -r, cp -R, less -r, less -R)

grep -R, grep -r, cp -r and cp -R all recurse into subdirectories. Sed and less don't because what would that even mean?

sed and less can both look at multiple files (sed with --in-place, and less always). sed -r is extended regexp (as opposed to -E in grep - why? who knows), less -r is to disable control character filtering, and less -R is to disable control character filtering for color codes only.

With a well-designed graphical UI, options and menus are (or at least should be) easily discoverable. But for text-based UIs, I'm forced to resort to scrolling through "man tmux" or "java -help", or etc. to find the option that I want.

It's human systems.

Cities, buildings, books, philosophy and theology all bear the marks of their time.

For me it becomes a modal guide: given XYZ attributes I can expecr MNO properties (usually).

As another commenter notes, GUIs have similar tendencies. And Web frameworks.

Said the other way, knowing the genealogy of a tool can allow a user to their existing experience, rather than starting from scratch.

One applies to lowering the bar for novice users, the other is a force-multiplier for experienced users.

The force-multiplier for experienced users would be even more powerful if each convention covered more utilities, and in the optimal case if there were only one (I can dream, right?).

I agree that it's very useful for an experienced user to learn the genealogy of all these tools for command-line wizardry, but they shouldn't have to.

But that's unlikely to happen.

A given utility exists in what are quite likely miilions if not billions of scripts / instances, each of which would have to be changed.

The only way to fix this is to go back in time.

NB: this is another reason to get shit right from the start. Which is what TFA is about.