6 ms·

In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from

In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from the name what it does. definitely a good pattern to just name things what they do.

dang 7y ago
That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.
- liability 7y ago
  I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO. Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems. A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.
  - Izkata 7y ago
    Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.
    - liability 7y ago
      Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.
      - Izkata 7y ago
        To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.
    - madhadron 7y ago
      You need a better completion system.
  - dang 7y ago
    I don't think the argument has to do with speed of typing; that is a minor concern, since the bottleneck is thinking of what to type in the first place. The issue is the intelligibility of the resulting program. That probably sounds counterintuitive, because people always say that long explicit names make code more readable—but this is only true of code locally. It is not true of programs as a whole. Using long names makes programs longer, as does factoring out subsections into functions and naming those functions. A longer program is harder to understand than a shorter one, and the delta expands non-linearly as system size grows. There's a deep tradeoff here, much deeper than the popular discourse around software development has ever accounted for. You can see this come up in the OP where the author introduces functions (listAttachment and attachmentInfoLineToAttachmentId) into the example without including their definitions, which would probably double the size of the example. If you have a rich set of orthogonal, composable primitives, you can do powerful things in a line or two that would require 10x or even 100x more code in other environments. The tradeoff is that you have to actually learn the primitives to the extent that you become like a craftsman in a workshop whose tools are all at hand and who can reach for each one as needed without thinking. If you don't know the primitives, of course that line or two will be inscrutable.
    - liability 7y ago
      IMHO CamelCase is the offender, not the length of the symbol. (CamelCase kills local readability, and therefore global as well) lisp-style-hyphenation is readable to me, even when long. If it helps the code read like prose, all the better.
- Aqueous 7y ago
  True, but personally, I think this a cost well worth paying for intelligibility and self-documentation. In my opinion, documentation and clarity is more important than maintaining programmer's flow and being economical with command length (and therefore typing time), especially with newer tools that manage a command-line history better. Clear command names pay dividends that outweigh the cost of repeated typing. The dividends come when another person inevitably picks up the shell script you wrote or the documentation you've written to ramp up - and they might not have yet achieved the same level of fluency with the command line. For them these commands might not come pre-integrated. I would never accept a function in a code review named 'xargs' no matter how much of a short-hand convention it became. I think many company styleguides enforce similar rules for code. Why should command line tools be any different?
deleted 7y ago
[deleted]
gumby 7y ago
xargs and cut do describe what they do.
- Aqueous 7y ago
  Only sort of, and cut much more than xargs. in fact, to a newcomer, seeing xargs in a command pipeline would I imagine be completely unintelligible until reading the man pages, as it was to me the first dozen or so times I encountered it.

dang 7y ago

That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.

liability 7y ago
I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO. Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems. A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.
- Izkata 7y ago
  Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.
  - liability 7y ago
    Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.
    - Izkata 7y ago
      To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.
  - madhadron 7y ago
    You need a better completion system.
- dang 7y ago
  I don't think the argument has to do with speed of typing; that is a minor concern, since the bottleneck is thinking of what to type in the first place. The issue is the intelligibility of the resulting program. That probably sounds counterintuitive, because people always say that long explicit names make code more readable—but this is only true of code locally. It is not true of programs as a whole. Using long names makes programs longer, as does factoring out subsections into functions and naming those functions. A longer program is harder to understand than a shorter one, and the delta expands non-linearly as system size grows. There's a deep tradeoff here, much deeper than the popular discourse around software development has ever accounted for. You can see this come up in the OP where the author introduces functions (listAttachment and attachmentInfoLineToAttachmentId) into the example without including their definitions, which would probably double the size of the example. If you have a rich set of orthogonal, composable primitives, you can do powerful things in a line or two that would require 10x or even 100x more code in other environments. The tradeoff is that you have to actually learn the primitives to the extent that you become like a craftsman in a workshop whose tools are all at hand and who can reach for each one as needed without thinking. If you don't know the primitives, of course that line or two will be inscrutable.
  - liability 7y ago
    IMHO CamelCase is the offender, not the length of the symbol. (CamelCase kills local readability, and therefore global as well) lisp-style-hyphenation is readable to me, even when long. If it helps the code read like prose, all the better.
Aqueous 7y ago
True, but personally, I think this a cost well worth paying for intelligibility and self-documentation. In my opinion, documentation and clarity is more important than maintaining programmer's flow and being economical with command length (and therefore typing time), especially with newer tools that manage a command-line history better. Clear command names pay dividends that outweigh the cost of repeated typing. The dividends come when another person inevitably picks up the shell script you wrote or the documentation you've written to ramp up - and they might not have yet achieved the same level of fluency with the command line. For them these commands might not come pre-integrated. I would never accept a function in a code review named 'xargs' no matter how much of a short-hand convention it became. I think many company styleguides enforce similar rules for code. Why should command line tools be any different?

deleted 7y ago

[deleted]

gumby 7y ago

xargs and cut do describe what they do.

Aqueous 7y ago
Only sort of, and cut much more than xargs. in fact, to a newcomer, seeing xargs in a command pipeline would I imagine be completely unintelligible until reading the man pages, as it was to me the first dozen or so times I encountered it.