Hacker News Reader

Comment by sprash | Hacker News Reader

If anything the vt100 ttys are just as suitable as ever. Command line interfaces are superior even today because the step from interaction to automation is as minimal as possible. I predict that the futuristc VR GUI of tomorrow will still be just a bunch of vt100 terminals floating in space.

View on HN

Can't we dream bigger though? For instance, I feel like templeOS's command line is unironically conceptually superior than the linux commandline or any other unix. I should be able to mix text with 3d models or images or sound, pipe them between programs, etc. I should be able to pause a running program, save it to disk, and resume it later. There are all sorts of things that I should be able to do but can't, because of the deliberate unix fetishization of 1970s era computing.

>Command line interfaces are superior even today because the step from interaction to automation is as minimal as possible.

Agreed completely. In fact, the OS should force GUI programs to all speak a coherent language so that you can automate them and pipe data between them. And if the machine is going to serve the user, the user should be in control of the GUI, they should be able to move buttons and UI elements around into the configuration they prefer. This would only be possible if GUI programs had minimal control over actual UI layout, which would make webdevs angry. But given the state of web UI, I think that's an acceptable sacrifice.

Much of the above was possible in lisp machines. But sadly I don't think it would be possible to create such an OS today (unless the "OS" is running in a linux VM and using linux for the actual hardware interface) due to the sheer diversity of hardware. And the closed source nvidia driver would ensure that you never got cool graphics.

In my opinion the mistake was to move away from the terminal in the first place. Many gui commands like "draw button in bottom right corner" could be done via escape codes and creating a gui program would be as simple as writing a bunch of commands to stdout. As far as I know the earliest prototypes of X worked just like that.

Well, X developers must've abandoned that idea for a reason.

X was meant to be a lowest common denominator for Unix workstation vendors to base their proprietary software, window managers and desktop envrionments on. Too much standardization at that point would have meant less distinguishing features for their products. Today all major unix workstation vendors are dead which shows they were clearly wrong.

There is a library for doing things like that; for some reason, it's called "curses".

I believe that's how the MGR window system, from Bellcore, worked. I fiddled around with it briefly on an old Sun Workstation many years back.

https://en.wikipedia.org/wiki/ManaGeR

I think the problem is conflating "dreaming big" to "no restrictions." A large part of the strength of the current terminal approach is specifically its limitations.

That is to say, a large part of what makes the automation capabilities of most terminal applications so strong is specifically that the idea of character streams over raw binary streams being the default.

Can I dream of a lisp machine that lets me do what you are suggesting? I mean, sorta. Early HTML based apps came pretty close on this, but folks regularly refuse to limit themselves to a base set of constructs. Is why it would be easy to user style HN, but basically impossible to do the same to gmail. (gmail, amusingly, created their own theme capabilities...)

Reply on news.ycombinator.com