5 ms·
One thing the author's missing is a consideration of how often a system is used vs. how often it's learned. Let's just take one example from the article. Would
by dcolkitt 7y ago
One thing the author's missing is a consideration of how often a system is used vs. how often it's learned. Let's just take one example from the article. Would it have been better if `sed` had been named `streamEditor` from the start?
sed was written in 1973. Think about that, it's been around for half a century. It's regularly used by millions across generations. Imagine how many countless man-hours have been saved from naming it "sed" instead of "streamEditor"? And I'm not just talking about typing code, but also reading code.
Yes "sed" is pretty inscrutable if you don't know Unix. But pretty much any Unix developer or sysadmin instantly recognized "sed" the same way they would a common English word. Very few people just use the Unix command line tools a few times, then forget about them. Once you learn Unix, chances are you'll keep using it for decades. And for those people, their brains almost certainly parse "sed" much faster than they would "streamEditor".
So, I think here's the lesson. The utility of terseness is very much related to the relative balance of expert users vs novice leaners. If you expect your system to mostly be repeat power-users, then terseness is very good. Systems that are around for decades, used widely by thousands, and general-purpose frameworks tend to fall in this category. In contrast, a high percentage of your user's man hours may just be people getting acquainted with the system. Maybe it's an application that solves some niche corner case, and most people use it once or twice then forget about it. Or maybe it's some internal software, where corporate turnover means that most devs working on it at any given time are neophytes. In this case verbosity and explicitness is a very good thing. You're not trying to cater to power-users. You want things to be as clear as possible, even if it means a lot of typing and spelling errors and wasted screen space.
The challenge here is that you mostly need to make these decisions at the development stage. You have to try to predict what your user-profile will look like, before you actually have any users. I doubt the original authors of sed could have ever imagined how popular and lost-lasting it would become. But given that it has, there's no doubt they made the right choices.
- bsaul 7y agoOn another hand, imagine if the original computers on which unix commands were designed weren't restricted to 80 characters terminals with a few kilobytes of memory and almost no storage nor CPU. I'm pretty sure the author would have favored much more expressive commands. I think design of those command lines were done first and foremost because the underlying system constraints were huge. Now that we have tabs autocomplete on shell and IDEs, the length of a command pretty much doesn't have any kind of importance.
- kmdupree 7y agoamen. well, I'll walk that back just a touch: I can see someone plausibly arguing that it may take longer to read longer commands. In that case, I'd argue maybe we need multiple views of the same source: one view for novices and one for experts.
- bsaul 7y agoThe first time i encountered really long names (on purpose, as opposed to java-gone-wild frameworks) was with objective-c. It shocked me at first, but since the parameters are spread along the method call, just like in a regular sentence, it really didn't matter, and actually made the code really nice to read. This style is nowaday pretty common with named parameters in function calls.
- michaelmrose 7y agoFor interactive use I don't want to rely on autocomplete to enter 20 character commands instead of 5 characters.
- teddyh 7y ago> I'm pretty sure the author would have favored much more expressive commands. The very first compiled computer language was designed to be very expressive and able to be read almost as English, and be simple to read and understand. Would this be what you wanted? Would you change your mind when I tell you its name is COBOL?
- lostmsu 7y ago> Very few people just use the Unix command line tools a few times, then forget about them. I think that claim might be dubious. I imagine most people ever using sed/seeing it in a command behave exactly like that.
- ckosidows 7y agoAgreed. I only just started using Unix commands for the job I started a year ago. It's quite possible I won't need them for my next job/team and I will certainly forget most of the commands I have memorized. Not saying I'm the standard here, but us passable Unix users exist.
- BeetleB 7y agoBeen using UNIX for over 2 decades, and as my only OS at home for over 15. And I use the vast majority of UNIX tools (including sed) only occasionally. For me it's just a lot easier to write it in Python (and these days, even easier in Xonsh). Because even when I read the man page of some of these tools, I have to experiment multiple times till I get the command right. And if I ever have to revisit it months later, it's inscrutable, whereas my Python code isn't. In my experience, the following are the types of people who know UNIX tools really well: - People in IT who need to do a lot of shell scripting - People who are forced by the company/environment to do a lot of work in a constrained UNIX environment (e.g. embedded) - People who really want to be UNIX command line gurus (extreme minority). The majority of UNIX/Linux users do not fall into any of these categories. They may be overrepresented on HN, though.
- kmdupree 7y agoThis is a good way of thinking about this. I think the ideal solution may involve multiple views of the same source code. Experts and novices can switch to different views depending on their level of familiarity. I actually think the same thing could exist in non-bash contexts.
- Yizahi 7y agoI disagree. Unless you are talking about lets say "real" experts e.g. people literally living in the shell for years and doing all stuff in it, I think it is pretty much impossible for less regular users to remember command flags or deduce their meaning looking at them. I use ssh and scp daily but for the life of me I can't remember which one uses -P or -p for port and I still constantly guess wrong. Some common stuff like ps or ls - who the hell knows what those obscure flags mean? I just remember "magic" set of flags for each command and use them every time. Unpack tar or tgz? Impossible without man first. And the list goes on. Again - I'm using shell daily, I remember "some" stuff and I can deduce meaning of small part it, but still general rule is - shell is arcane magic and has to be googled or looked up in man.
- userbinator 7y agoI think that's largely due to inconsistency more than anything else. As with a lot of other things, you don't need to memorise all the options, just the ones that you use the most.
- shakna 7y ago> Unpack tar or tgz? Impossible without man first. tar has inbuilt format detection nowadays. Just specify extract (either with an x or --extract). GNU tar has supported it since before 2010, and bsdtar from around the same time frame. Debian lagged a bit, but can also do it. tar --extract --file FILE It isn't archaic or hard to remember anymore.
- mistahenry 7y agotar is easy. Just pretend you’re Arnold Schwarzenegger “eXtract Ze File” for tar -xzf. And to create, “Compress Ze File” tar -czf
- chupasaurus 7y agoAnd then tar has -J for xz format.
- userbinator 7y agoBut pretty much any Unix developer or sysadmin instantly recognized "sed" the same way they would a common English word. That's the key point. We talk about grepping and piping and sedding and sudoing as if they are English words, because they've effectively become part of the vocabulary.