4 ms·
Although, through a long career, I've become accustomed to a wide variety of CLIs, I tend to agree: We've moved beyond 1999 a bit. The fact that a lot of these
by ubuntourist 10y ago
Although, through a long career, I've become accustomed to a wide variety of CLIs, I tend to agree: We've moved beyond 1999 a bit. The fact that a lot of these systems have legacy and tradition isn't sufficient. Languages like COBOL also have a long history. But now we have lots of other languages to choose from.
First off, as much as possible, I'd eliminate non-words. I tutor a lot and people think perhaps I have a speech impediment the first time I say "grep". (Yes, I know, it's not technically part of the shell. But okay how about "fi" and "esac"? Really? Why not "enod" then?)
I'd take command completion further: IDEs often have drop-downs and function signature descriptions as you move along coding. In a hypertext world with tooltips, etc, I think there's be a lot of room for those types of ideas.
I do think the philosophy of "do one thing and one thing only, but do it well" is a good one. Piping stuff together is wonderful. I wonder if it would make sense and be shorter to explain in plain English, if the "water flowed the other way" instead. For example:
"sort the output of the find result" = sort | find
as opposed to:
"take the output of find and sort it" = find | sort
(That last bit was just a random thought of the moment, just trying to think a wee bit outside of the box.)
- saynsedit 10y agoIt wouldn't be enod, it would be rof