Hacker News Reader

Comment by ceving | Hacker News Reader

The current Unix command line situation is on the one hand "incredible useful" and on the other hand "broken by design".

Why is it incredible useful?

Just imagine how long it would take to write the following in C or Rust:

    curl -sS https://go.dev/doc/devel/release |
      html2text |
      grep -o -P '\bgo\d+\.\d+\.\d+\b' |
      sort -V |
      uniq |
      tail -1

Why is it broken by design?

Read this: https://news.ycombinator.com/item?id=29747034

The problem: a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

View on HN

> Why is it broken by design?

I think your example self-explains why it's broken by design. It's a good example.

> a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

And you know, there could be one. Apple has Human Interface Guidelines to reify the meaning of the visual abstractions in its desktop UI. The problem is that the command line didn't come from people who think like Apple designers; it came from people who think "How can I express what I want using the least code possible, because laziness, impatience, and hubris are virtues?" And they weren't wrong for the time (especially because every byte matters), but the design decisions they made got baked into tooling that can't now be moved.

I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have.

I think graphical user interfaces are no high standard. They do not compose. How would you express a loop or a recursion in a graphical user interface?

They are a challenge for composition, often.

Great for discoverability though, and that doesn't require graphics, just context.

There should be a button I can push in my shell that lets me ask "what does the token at cursor mean," and a button that lets me type a plain language search string that wires down to a contextual search (i.e. I'm in the middle of typing out "grep" I should be able to ask "how do I search folders?").

We didn't have the tools to build this when grep was invented; we have them now.

I'm genuinely unsure how to translate your question into, hmm. Anything actually.

The snarky answer is "By writing it in source code, in a GUI text editor", a thing I do frequently. But the problem is that I have no idea what you're getting at in the first place, so that's just an attempt to recover some meaning from what you wrote.

Shells allow one to pipe around the data flowing from called process to called process in a very smooth and transparent fashion.

By and large, GUIs do not. There is no such thing as a universal shell for GUIs, and attempts to layer automation atop the GUI abstraction are generally spotty and unreliable (certainly when compared to CLI and shells). This is both for technical reasons (i.e. it's much easier to clearly delineate the two ends of a pipe than to clearly delineate "I want to click on the red square inside the 'diagram' window inside the drawing app") and for ecosystem reasons (since GUIs aren't thought of as automatable, GUI designers are free to move pieces around version-to-version of software, making it extremely challenging to describe a GUI structurally).

I've seen some neat attempts at GUI automation (Sikuli is my favorite) but it's never been a core feature like it is in the CLIs-glued-together-by-shells world.

CLIs are in the modern world a subset of GUI programs which run inside a text-oriented window, and plenty of more sophisticated GUI programs can be directed textually, with macros or short scripts, and/or have a command-line component for doing that sort of pipe or batch-oriented work.

Yeah, sometimes there's functionality stuck behind a button or menu select which I want exposed in a more textual way, in macOS that's when you break out Automator, Alfred, or Hammerspoon (the only one I've ever used fwiw), Linux and Windows have their own equivalents.

I don't think the distinction you're pointing to is nearly so stark or clear-cut as it's often made out to be. Ecosystems converge towards the tasks which are amenable to batching and pipelining being equipped to do so.

But in general, batching and pipelining are done via a text-based interface. Extremely rare is the teachable GUI interaface where there's a point-and-click way to describe the concept "See these five items I clicked? Do that twenty-eight more times with this radio button family swizzled via a linear sweep."

My point being, I don't see why there ever should be. A text window is a valid and frequently-included part of GUI programs (I happen to be using one this instant, in fact), so there isn't a lot of advantage in replacing something like Lua scripting with a bunch of buttons and whizbangs. It's been tried for normal programming, and no one likes it.

The specific kind of task you described is frequently exposed as macros in programs complex enough to deserve it.

> so there isn't a lot of advantage in replacing something like Lua scripting with a bunch of buttons and whizbangs

I mean... "no-code development" is an entire category of product offerings. People are positively thirsty for being able to do that sort of thing without having to learn to love staring at giant blobs of text all day.

> I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have.

Posix could potentially do this. It already has a bit about conventions and could be expanded. Problem is getting things to adhere to it, plus I doubt the posix authors could be convinced to add a lot more to it.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

> The problem: a command line interface must be human readable and machine readable at the same time.

Since the computer is there to serve us, ultimately the solution must be for the machine to read as well as humans.

What if the ultimate solution is only achieved after our lifetimes?

I don't really understand the question. Nobody got to fly until we figured out how to build airplanes, people before that lived on the ground. Likewise, we'll live with iterations on the current command line, until AI is fully integrated with it.

Never ever. Humans are idiots. If you build machines like humans you will get idiotic machines. Machines need to do things exactly right and not almost right or mostly right. Current AI trends will not create better machines, just more idiotic machines. Those idiotic machines will be sufficient to impress idiots, but they will not help to do things exactly right. Automated theorem proving is the only way to build better machines.

> Automated theorem proving is the only way to build better machines.

Sure, but that will just be one aspect of an integrated and wholistic AI, which can configure the parameters input to the automated theorem proving component, and act on the results.

Automated theorem proving will only ever be an arrow in the quiver, because even in theory, the space of useful computer programs is a vast superset of those which may have all their properties formally verified. In practice, it's a much larger superset than theory allows. Growing the space of formally verifiable subprograms is a worthy endeavor, sure, but so is good old-fashioned engineering.

> Automated theorem proving is the only way to build better machines.

That is only true for a very narrow notion of "better machines". Automated theorem proving is still light years away from being applicable in the majority of software projects. Don't get me wrong I am aware of the progress made in the last decades. Yet, it will be some time until someone writing the next iOS app will reach routinely for an automated theorem prover to lower the defect rate.

And even then, the questions remains whether fulfilling a formal specification is at all correlated with "better machines" or "better software". There are domains where this is conceivable: os kernels (L4), certifying compilers (CompCert), and others. But how does a theorem prover, automated or not, help with improving the next generations of video codecs? That is an intrinsically subjective problem -- the quality axis, less so the performance axis. How does theorem proving help with neuronal networks? How does it help with capturing the right business process to actually improve business outcomes and not just introducing new bureaucracy?

> The problem: a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

It's not really the "same time". Usually, human and machine use the same command, but at different times. And there are many ways to enable different outputs, even at the same time. But this all depends on having some standard which everyone follows. And that's where it becomes complicated.

Your example not only doesn't prove that it's broken by design (only broken most of the time ?), it even seems to give a (relatively ?) easy way to fix it ?

> Since very few implementations of ls allow you to terminate filenames with NUL characters instead of newlines

In fact the solution to this issue seems to be so obvious that I might be missing something ? (Rejection by shell interfaces for some reason ??)

The article covers this. Special machine-readable output modes like `--json`.

> The problem: a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

* Powershell has entered the chat

Powershell has some cool things, but it's a disaster when it comes to usability.

how so?

Possibly due to overly verbose cmdlet names e.g. `Get-TrustAuthorityKeyProviderClientCertificateCSR`.

Could you please explain what that command does.

If you assume a similar set of primitives, it could be as simple as

   html2text(get("https://go.dev/doc/devel/release")).find_all("\bgo\d+\.\d+\.\d+\b").sorted().unique().last()

It's just that Rust is designed to be more robust in exchange for stricter Compiler time checks.

Reply on news.ycombinator.com