Hacker News Reader

Comment by wiseowise | Hacker News Reader

> The reason why the CLI is good is because it _can't_ do most things people want it to do.

-1. You’ve lost me here. The reason why CLI is good because it solves problems that even modern GUIs can’t, not because of some artificial limitations or lack of convenient defaults.

> Which means you have to think when making an application.

“Think” and “remember obscure syntax that greyheads keep on a paper under their mattress” are two different things. I agree with the author that sensible defaults are severely lacking from some of the tools.

View on HN

one great property of the terminal is that it’s not a continuous canvas. it’s a grid of discrete cells, just as it is natural for computers to be. instead of laying interactive objects out in virtual space, you’re pushed to think in discrete states and discrete actions. so I say cli is, indeed, good in part due of its limitations.

edit: i’ll add that continuousness of guis is actually its limitation. a terminal interface is indexable, a gui is not. so what looks like freedom is actually a different structure. a gui is more general, as real numbers are more general than whole numbers. but to get to whole numbers, you have to re-constrain real numbers. this is left up to the developer to create a constraining framework. and it’s a path of less resistance to not do this. most data we deal with is discrete. so a continuous representation of it is a mismatch of structures. terminals force you to stay in that same discrete space. so your solutions are from the getgo closer in fit to your data.

it’s important to match up the structure of your interactive surface with the structure of your domain. it’s a common principle we talk about too little.

I think that's it, although I don't think I'd describe it as a grid, but as a 1d list. The core concept of CLIs is linear. That's in part why streaming works so effectively in CLIs, because the linear medium clicks really well with the idea of streaming data. And actually the fact that a lot of UNIX commands actually operate on a graph of sorts under-the-hood is where you can see some of the limitations of this linear approach (eg trying to pipe one stream to multiple paths with each path having its own processing requires a branch which is inherently a little difficult to represent in a linear system).

You can lay things out in a grid, but the same can be said of GUIs. You can consider each character a cell in a grid, but I think that's so small that at that point it's not conceptually sufficiently different from being continuous. The computational paradigm that's a grid at its core is spreadsheets.

Exactly, they conflate the fact that the CLI tool is just a "programmable API view" of an app, and that GUI is more of a "interaction view", with the fact that it can or cannot do some stuff

Now with AI and better design, nothing in theory would prevent us to "script UI apps" like we do with terminal, you could say

"take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app"

and you would get the same pipeline

of course "UI apps" just have too many input / output possibilities, and you wouldn't want to have "--flags" everywhere for every possibility

But that's where "natural language as a universal API" applies, or perhaps just a better design for interaction with UI apps

> "take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app"

This is basically Apple Shortcuts. It would be nice to have a CLI interface for Shortcut "actions".

Yes they can, since Xerox PARC and Genera, it is called a REPL and scripting.

Reply on news.ycombinator.com