Item — HN Reader

I wish the authors thought a little bit more about the actual physicality of typing out commands. `exa` on a QWERTY keyboard is typed on one hand, across three rows, and with the weakest fingers. I guess I could put this into muscle memory, but I expect an `ls` like command to be ergonomic to some degree and I see myself making a lot of typos.

5 comments

I guess. Nothing’s stopping you from remapping ‘ls’ to exa. That’s what I did.

I've been doing this -- it's annoying for things like "ls -rt" and other commands that you may or may not use often.

Yeah, I just use \ls -whatever for those.

I put some thought into that naming https://github.com/c-blake/lc which I think is basically uniformly more capable than exa.

You better not switch your keyboard layout to dvorak... 'ls' are both right pinky letters. ;)

This is a basic flaw in the design of unix. The user interface is coupled to the implementation. To accomplish a task, you don't describe the task - you write the name of a program that executes that task. Once a program is named, no other program can be named that ever again.

Imagine if programming languages worked that way.

aka "lacks namespaces"... but it isn't so. The namespaces are paths and they're "linked" by $PATH. /usr/local/bin is a namespace. Is it guaranteed to be a fully qualified namesake? No. But your sysadmin (now Docker) is in charge of that. You can plan a system that forces everyone to use fully qualified nameplates, but you can't force people to use the system. That's why unix/posix/Linux remain the lowest common denominators.. by making fewer assumptions they retain a different flexibility that makes them useful for gluing together the ornery systems designed by all you planners.

I don’t understand the programming languages analogy, can you elaborate? One way to interpret that is “s/program/function, class or module/g“, but that sounds strange to me.

That was indeed the thrust of the analogy. Basically, we try to design programming languages so that the interface is decoupled from the implementation. A function should have an intuitive, descriptive name that reflects what it achieves, free of such terrestrial concerns as who wrote it, and when, and whether a different person decided to fix a bunch of bugs in it. But commands in Unix exist in a single-layer, permanently immutable namespace. Someone wrote the canonical 'top' once upon a time and now all evolutions on the concept must use names like "htop" and "vtop" and "gtop" and "ptop". By 2121 we'll have exhausted that namespace too, and be on to "aatop", "abtop" etc.

Good interface design is stable, even as the backend tech improves. Both a go-kart and the NASA crawler-transporter have steering wheels, because the wheel is an affordance for the human, not the machine. But on a Unix system, there's huge churn in how to do things - usually for no better reason than that it would break a bunch of stuff to change how the old way works, so better to simply add a new way. Someone wrote an improved version of grep - does that mean we get grep v2? Nope, we get "ripgrep", and old grep stays permanently...

The worst of it is, that namespace doesn't even guarantee anything! It would at least be some consolation if 'ls' worked identically on every system, but alas...

That is a good thing, which I wish more package systems used. In popular programming package managers that use “semver”, bumping a major version usually breaks all of the internet and then some more. If you don’t believe it, just search for a non-trivial gulp or webpack recipes and it will come. The fact that ls is always the same (except for bsd and few non-standard options) is very useful when you plan to run your system for years+. Personally I don’t want to learn ripgrep, grep and aliases I have in my .profile are fine by me, and there is no reason for me to spend time to replace them with shiny new.

Interesting but there's no alternative presented. Any large software project typically has a fixed api that can't be drastically changed due to backward compatibility.

No reason to tie it to Unix either, other than it being ubiquitous.