The terminal of the future

I dread reading these articles written by people who perceive the command-line interface / terminal / shell to be this archaic system, and propose "modernizing" it by cramming whatever UI/UX they're most familiar with.

The last thing a command-line terminal needs is a Jupyter Notebook-like UI. It doesn't need to render HTML; it doesn't need rerun and undo/redo; and it definitely doesn't need structured RPC. Many of the mentioned features are already supported by various tooling, yet the author dismisses them because... bugs?

Yes, terminal emulators and shells have a lot of historical baggage that we may consider weird or clunky by today's standards. But many design decisions made 40 years ago are directly related to why some software has stood the test of time, and why we still use it today.

"Modernizing" this usually comes with very high maintenance or compatibility costs. So, let's say you want structured data exchange between programs ala PowerShell, Nushell, etc. Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly. So now instead of creating an open standard that everyone can build within and around of, you've built a closed ecosystem that has to be maintained centrally. And yet the "archaic" unstructured data approach is what allows me to write a script with tools written decades ago interoperating seamlessly with tools written today, without either tool needing to directly support the other, or the shell and terminal needing to be aware of this. It all just works.

I'm not saying that this ecosystem couldn't be improved. But it needs broad community discussion, planning, and support, and not a brain dump from someone who feels inspired by Jupyter Notebooks.

> Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.

Yes, this is the work. https://becca.ooo/blog/vertical-integration/

Nonsense. It's just some person brainstorming improvements. You shouldn't need "broad community discussion" every time you toy with some ideas.

I cannot agree more. The most perfect terminal of the future will be the terminal of today. Leave it the heck alone. Terminal Emulators (1984 for MacTerminal), Vi (1976 by Bill Joy then 1988 by Bram Moolenaar for Vi IMproved) and Emacs (1976 by David A. Moon and Guy L. Steele Jr. then 1984 for GNU Emacs by Richard Stallman) are extremely primordial ancient programs. Among the oldest programs still in active use. There is a reason for that. During my evolution with technology, every time I wanted these programs to do something "familiar", it was because of my own ignorance and lack of familiarity. As I became familiar, I slowly realized that their power is in their simplicity. Not everything needs to be improved. "There is more to life than speeding it up" - Mahatma Gandhi

Currently being discussed at https://news.ycombinator.com/item?id=45891772

I think this will be like the Fish shell, where backwards compatibility is left to existing tools, but a fresh environment is available going forward.

No, the problem is that the proposal is not enough *bold*.

A "barely better" version of something entrenched rarely win (maybe only if the old thing not get updaters).

This is the curse of OpenOffice < MS Office.

This is in fact the major reason:

> Great, now you just need to build and maintain shims for every tool in existence

MOST of that tools are very bad at ux! so inconsistent, weird, arcane that yes, is MADNESS to shim all of them.

Instead, if done from first principles, you can collapse thousands of cli arguments, options, switched and such things in few (btw a good example is jj vs git).

This is how could be: Adopt an algebra similar to the relational model, and a standardized set of most things millions of little tools have (like the commands help, sort, colors, input/output formats, etc) and then suddenly you have a more tractable solution.

ONLY when a tool is a total game changer people will switch.

And what about all the other stuff? In FoxPro (that in some ways show the idea you just preen `!` and then run the shell command you need. That is enough (editors and such? Much better to redo in the new way, and everyone knows that vim and emacs fan never change ways)

> I'm not saying that this ecosystem couldn't be improved

Yes, you effectively are, and the current unstructured buggy mess is "just works" for you.

> But it needs broad community discussion, planning, and support,

Where was this when all the historic mistakes were made? And why would fixing them suddenly needs to overcome this extra barrier?