Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The terminal of the future

jyn.dev

Post reply on HN
Print view View original

21–30 of 174 posts

Re: The terminal of the future

#21

Post by unixplumber »

wredcoll wrote: post #4
add-sub-mul-div wrote: post #3

Earlier quoted context omitted.

That would be quite an own goal, to invite an extra middleman into the mix. Especially when so many people will go the path of least resistance and use a tech giant product as that middleman.

I mean, what is a terminal emulator? It's a program that displays the output of other programs "inside" it. Terminal emulators display grids of characters using all sorts of horrifying protocols. Web browsers display html generated by other programs.

> Terminal emulators display grids of characters using all sorts of horrifying protocols.

What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.

Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.

Re: The terminal of the future

#22

Post by shellkr »

Etheryte wrote: post #15
shellkr wrote: post #9

This I am afraid does not feel as the right thing to do. I think the KISS-principle is a good standard to follow and while terminals have to do more than one thing, it should not do everything. Complexity leads to instability. Terminals has to be nimble and not clumsy behemoths like web browsers.

Terminals are far from simple, that's the whole problem. We carry the weight of decades of technical constraints and arbitrary decisions on our shoulders every time we fire up a terminal emulator.

I am all for removing old junk but not that it should be replaced with newer junk.

Re: The terminal of the future

#26

Post by mrandish »

wredcoll wrote: post #2

The terminal of the future is called a web browser.

Yes, this was my first thought too. I haven't used a hardware text terminal since the 80s so maybe I don't get where the TFA is coming from? It starts out by stating "This post is part 6 of a multi-part series called 'the computer of the next 200 years'". Given that context, why is the focus on the evolution of 1980s VT100-type protocols? I'm at home and there are over a half dozen different devices within 25 ft which come standard with an HTML browser. Sure, modern browsers have some incompatibilities at the edges but if you're in need of a multi-decade, platform agnostic, lingua franca then W3C minimal baseline HTML/CSS + ECMAscript seems like the obvious winner (with no viable second place really).

Don't get me wrong, I'd be quite interested in a vintage computing discussion on the evolution of VT-100/220 etc terminal protocols. There were some interesting things done into the 90s. That's actually what I clicked in expecting. Of course, those were all supplanted by either XWindows (which I never got to use much) or eventually HTML/CSS. And if we're talking more broadly about structured page description languages, there's no shortage of alternatives from NAPLPS to Display Postscript.

Re: The terminal of the future

#27

Post by imiric »

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.

Re: The terminal of the future

#28

Post by kloud »

Great thought provoking article! Indeed, typing commands on the command line feels primitive like typing code into interactive interpreters (python, irb, etc.). Those are primitive REPLs.

With lisp REPLs one types in the IDE/editor having full highlighting, completions and code intelligence. Then code is sent to REPL process for evaluation. For example Clojure has great REPL tooling.

A variation of REPL is the REBL (Read-Eval-Browse Loop) concept, where instead of the output being simply printed as text, it is treated as values that can be visualized and browsed using graphical viewers.

Existing editors can already cover the runbooks use case pretty well. Those can be just markdown files with key bindings to send code blocks to shell process for evaluation. It works great with instructions in markdown READMEs.

The main missing feature editor-centric command like workflow I can imagine is the history search. It could be interesting to see if it would be enough to add shell history as a completion source. Or perhaps have shell LSP server to provide history and other completions that could work across editors?

Re: The terminal of the future

#30

Post by jynelson »

imiric wrote: post #27

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 t…

> 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/

Post reply on HN