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

State of the Terminal

gpanders.com

Post reply on HN
Print view View original

111–120 of 159 posts

Re: State of the Terminal

#111

Post by orangecat »

9dev wrote: post #96
orangecat wrote: post #75

Earlier quoted context omitted.

tooling shouldn't need to parse strings to do something useful; and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response Absolutely. Glad we fixed all that with CSS...

Could you share what you mean by that? I suppose it was sarcasm, but I didn’t get the point.

Ha sorry, that was probably overly snarky. I was thinking of CSS's multitude of string-valued properties that effectively have their own DSLs, ranging from the simple "5px 10px 0px 10px" for padding/margins to much more complicated expressions for gradients and animations. And it's all stringly-typed so (without additional linters) you don't get told when you format values incorrectly or set mutually exclusive properties. But there are also lots of advantages in terms of flexibility and ease of use (the "API" is just "style.foo = bar"), and that's led to CSS being ubiquitous and extremely successful.

I think this applies to some of your complaints about terminals as well. Yes escape sequences are ugly, but it means I can just emit the appropriate bytes from any program written in any language rather than figuring out what library I need to import to generate a correctly formatted structured message, and operating on the byte stream level lets it transparently work across remote connections. I'm all for experimenting with new approaches, but we shouldn't lose sight of the existing benefits.

Re: State of the Terminal

#112

Post by theamk »

9dev wrote: post #17

I could never really understand the enthusiasm. Why are we still dealing with over half a century of cruft? I get that this is a core piece of technology lots of stuff is built upon, and I'm not arguing to get rid of the classic terminal emulation altogether. But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. We shouldn't need to…

Is there? Lets put a few reasonable requirements down:

- Self-sufficient commands that you can store in history, put on wiki page, put inside a script file, Slack to your friends, store in configuration, etc...

- Variety of execution methods: local computer, remote via ssh, jupyter-like notebook, remote via something else (like AWS SSM), CI runner, ssh which launches SSM session which connects over serial port, cron-like periodic schedulers, starting commands in your Go program etc... Every method should be supported automatically with no effort from developer.

- Output could be interactive (possibly with some reprocessing like tmux/screen does) or stored (like CI/cron execution). It is possible to parse output to get relevant details.

Even if you start from scratch, what can you design to fit this pattern? You'll get something very close to existing state - applications that take command lines, character-based input/output streams with some sort of formatting sequences.

Sure, if I could design from scratch I'd standardize on _one_ TERM, make escape sequences easier to parse (longer and common start/end chars), fix extended keys/numpad mess, redesign the CLI defaults of the few tools, create common command-line completion interfaces... but the overall idea will be the same.

(And if you don't care about the three requirements above, then go with HTML or native UI! There are tons of them and they are well supported. But I don't see the point of retrofitting HTML-like functionality to exiting terminals)

Re: State of the Terminal

#113

Post by argulane »

eej71 wrote: post #26
eminence32 wrote: post #3

A quick off-the-cuff remark based solely on the title: in 2024, I think the state of the terminal has never been better, in large part to Microsoft making a high quality terminal easily available to everyone on Windows [1] As an application author, I love being able to assume that all major platforms have a good terminal and that my favorite terminal rendering libraries should Just Work on all of them [1] https://git…

I mainly use microsoft terminal now just beacuse it did a better job handling more of the font decorations (italic was one that I recall). My one gripe though is that it seems like microsoft terminal is still kind of slow at scrolling. If I accidentally grep for something that spews a lot to the screen, terminal is just plain hung up a bit. And for many of us - but not everyone? - control-space in emacs is just kind…

Have you turned on the new render engine in the microsoft terminal settings? It is marked beta but should be much faster.

Re: State of the Terminal

#114

Post by PurpleRamen »

9dev wrote: post #98
PurpleRamen wrote: post #86

Earlier quoted context omitted.

> But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. Would it be different from a web-browser? Isn't the webstack already the modern textual interface everyone is using? I mean that's also the direction they all are walking to, with adding images to terminals, having more complex layout with TUIs. I think I remember some TUI-toolk…

> Isn't the webstack already the modern textual interface everyone is using? I would argue that the web stack is really more of a virtual machine, or OS-agnostic application runtime, but it is not a textual interface per se (albeit it certainly can be used that way). On the other hand, I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to libe…

> I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation

JSON exists. YAML exists. XML exists. The lack of proper exchange-formats is not a problem. The lack of tooling is the problem.

> Think of what we had before systemd—the wild west of shell scripts

Liberty. And this gives you an answer why terminals, shells and cli in general remain this way. People have the liberty to do what they need, and they have the liberty to go as simple or complex as they want. And this works very well. Don't forget that not all output is structured.

So unless you have someone creating a whole new set of tools and environment which can compete with the established solutions, and beat them on ALL aspects, and is still compatible...until then people will not support it. I mean, there are more than enough alternatives who are barely popular for one reason or another. Speaks for itself.

> I'd like to see a new kind of terminal protocol that solves the UX issues of old.

Which are the issues? Is there some solid documentation on them?

Re: State of the Terminal

#115

Post by theamk »

MisterTea wrote: post #39
lambdaba wrote: post #14

Are there any efforts to radically reimagine the entire "terminal" concept? Seems very limiting to advance further in the 21st century with those same 70's technical assumptions. [edit] I was thinking more in terms of being unconstrained by low-res displays, inability to display anything other than text, etc.

Plan 9 dropped the concept and went graphics first using a 2D engine called devdraw which you load assets into and issue draw commands. Text is a first class primitive so drawing text is pretty simple. It has a shell but it lacks cursor control so stdout/stderr is written to the window's /dev/text - think of a window as a dumb textbox. If you need vt100 emulation you run the command in vt(1) which is a graphics progr…

that sounds like a replacement for X11/Wayland, not for the terminal.

and this of course sounds fine and nice, until you need to interop with other machines / OS-es - in which case you open vt and ssh to whatever location. Or you want your application to be callable by other machine (or via ssh or from script or cron...) - in which case you eschew all the draw commands and do good old print. And now we are back to where Unix is.

Re: State of the Terminal

#116

Post by wang_li »

9dev wrote: post #80
mandibles wrote: post #76

Earlier quoted context omitted.

While we're at it, can we get rid of staggered keyboards? We don't need to accommodate mechanical linkages from the bottom rows any longer, yet here we are. As other commenters have pointed out, once conventions and standards have been adopted, there is almost no way of dislodging them. It's a coordination problem. New standards and approaches usually need to be at least a 10x improvement over the status quo in order…

Im not so sure. We have HTTP3 now, which is binary. We use different image formats than we used to, and switched from horses to cars, too. Why shouldn’t we be able to innovate in this space? Building new walls doesn’t automatically imply tearing old ones down.

> Building new walls doesn’t automatically imply tearing old ones down.

But often in this space they seem to want to do that anyway. I can only imagine that they are attempting to force people to adopt their pet project. There's literally no reason a pair of sequences can't be specified that allows clients to query support for advanced terminal mode and get a response. After the client and the terminal have agreed on advanced mode, switch to a byte stream/command blocks/whatever which allow rich text, graphics, sound, access to UI devices, etc. Whan you're done you've recreated X11, but they can do whatever they like I guess.

There's no need to fuck up terminfo along the way though.

Re: State of the Terminal

#117

Post by hnlmorg »

pjmlp wrote: post #109
hnlmorg wrote: post #92

Earlier quoted context omitted.

Sure. And aside from Powershell, which itself had to recreate a bunch of common UNIX idioms, which of those other command line interfaces are still in widespread usage? The status quo is ugly but reinventing it is at least an order of magnitude more work than improving upon it.

Amiga DOS doesn't seem to go away no matter what. IBM and Unisys mainframes and micros. Smalltalk and Common Lisp REPL environments. Although probably debatable to consider any of them mainstream.

The fact that you opened your rebuttal with DOS basically proves the point I’m making.

> Although probably debatable to consider any of them mainstream.

The only person debating that point is you.

We could be online until the sun rises debating about different command line environments but if AWS (for example) haven’t released an official CLI utility for Amiga DOS then your position is ultimately just an academic one.

Re: State of the Terminal

#118

Post by 9dev »

theamk wrote: post #112
9dev wrote: post #17

I could never really understand the enthusiasm. Why are we still dealing with over half a century of cruft? I get that this is a core piece of technology lots of stuff is built upon, and I'm not arguing to get rid of the classic terminal emulation altogether. But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. We shouldn't need to…

Is there? Lets put a few reasonable requirements down: - Self-sufficient commands that you can store in history, put on wiki page, put inside a script file, Slack to your friends, store in configuration, etc... - Variety of execution methods: local computer, remote via ssh, jupyter-like notebook, remote via something else (like AWS SSM), CI runner, ssh which launches SSM session which connects over serial port, cron-…

There definitely are more options than applications reading and writing character streams, you’re just not even considering them because you’re too entrenched in the environment you’re familiar with. Take Powershell for example; the syntax may be horrible, but the way it passes structured data is truly different and way ahead of classic UNIX shells. The design space is huge; just dismissing any possible improvements before even sitting down and thinking properly is frankly not a good strategy.

Re: State of the Terminal

#119

Post by 9dev »

camgunz wrote: post #110
9dev wrote: post #100

Earlier quoted context omitted.

> Terminals deal with streams of bytes. But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead? > There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db. Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest meta…

There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.

Abstractions are layered a specific way, though. Layering upon something suboptimal will always be limited by the suboptimal layer.

Ncurses or bubbletea et all may hide it from you, but they still only paint over the bumpy legacy wall below without being able to really improve on it.

Re: State of the Terminal

#120

Post by pjmlp »

hnlmorg wrote: post #117
pjmlp wrote: post #109

Earlier quoted context omitted.

Amiga DOS doesn't seem to go away no matter what. IBM and Unisys mainframes and micros. Smalltalk and Common Lisp REPL environments. Although probably debatable to consider any of them mainstream.

The fact that you opened your rebuttal with DOS basically proves the point I’m making. > Although probably debatable to consider any of them mainstream. The only person debating that point is you. We could be online until the sun rises debating about different command line environments but if AWS (for example) haven’t released an official CLI utility for Amiga DOS then your position is ultimately just an academic one…

Amiga DOS !== UNIX CLI, and if you don't get why, well so be it, lets worship 1970's printer hardware instead.
Post reply on HN