6 ms·

This is a cute quote, especially if one's difficult decisions involve letting other men do the actual work. It does not really apply to software, where most go

This is a cute quote, especially if one's difficult decisions involve letting other men do the actual work. It does not really apply to software, where most good programmers are obsessive and hard working. Yes, that also applies to Lisp, where someone has to write the actual interpreters and compilers that others use to run their 100 macros on and pontificate how easy everything is.

runawaybottle 6y ago
Nope. Code is liability, I’d rather you not write shit (rhetorically) than write tons of shit (literally).
- lakiP 6y ago
  No one has talked about quantities here, and general statements like "code is a liability" are usually made by talkers.
  - runawaybottle 6y ago
    Good talkers inevitably sum it down, or good anything usually do. Conciseness can be a product of prolificness too.
  - jasonwatkinspdx 6y ago
    Ah yes, the famous "talker" Dijkstra...
- rschneid 6y ago
  Come now, I think we all know code is not its line count. 1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplishes the same task and only one person in the company understands...
  - deleted 6y ago
    [deleted]
  - lmm 6y ago
    Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.
    - Taek 6y ago
      https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf NASA averages something like 0.1 bugs per 1,000 lines of code, industry average is closer to 15. Surely there are other factors, like testing, linting, and language choice that influence the number of bugs.
    - manicdee 6y ago
      Without consulting Stack Overflow, describe the “...” operator in Perl. As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. Clarity is far better than terse code that suffers from leaning toothpick syndrome.
      - chromatic 6y ago
        Without consulting Stack Overflow, describe the “...” operator in Perl. Does it count as a trick question if I implemented it?
      - lmm 6y ago
        > Without consulting Stack Overflow, describe the “...” operator in Perl. I don't know Perl. But I'm prepared to do that exercise for APL if you want. > As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
  - deleted 6y ago
    [deleted]
  - dragonwriter 6y ago
    I've yet to see 1,000 (or even 100, and rarely 10) lines of code doing what could be done in a 1 liner that is both clear and correct, and generally the more verbose, the less clear and the less correct it is. Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.
    - TheOtherHobbes 6y ago
      It's not line count, it's the dot product of line count and conceptual clarity. There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be. It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
      - dragonwriter 6y ago
        > It's not line count, it's the dot product of line count and conceptual clarity. In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related. Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.
  - balladeer 6y ago
    Shorter code block doesn't mean unclear code. Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.
stanfordkid 6y ago
It applies to technology organizations though. I think being a smart engineer is very important when making architectural decisions -- but this is not always the bulk of the actual work. Lazy people tend to want to minimize total effort of the organization too.
MAJwlAL 6y ago
Typical downvotes: "Hacker" "News", a lot of whom think they are in the "smart and lazy" category, feels that their identity is threatened. Do you all think that Knuth was lazy, too? Delusion.
- skrebbel 6y ago
  do you make a new account for every comment somehow?

runawaybottle 6y ago

Nope. Code is liability, I’d rather you not write shit (rhetorically) than write tons of shit (literally).

lakiP 6y ago
No one has talked about quantities here, and general statements like "code is a liability" are usually made by talkers.
- runawaybottle 6y ago
  Good talkers inevitably sum it down, or good anything usually do. Conciseness can be a product of prolificness too.
- jasonwatkinspdx 6y ago
  Ah yes, the famous "talker" Dijkstra...
rschneid 6y ago
Come now, I think we all know code is not its line count. 1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplishes the same task and only one person in the company understands...
- deleted 6y ago
  [deleted]
- lmm 6y ago
  Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.
  - Taek 6y ago
    https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf NASA averages something like 0.1 bugs per 1,000 lines of code, industry average is closer to 15. Surely there are other factors, like testing, linting, and language choice that influence the number of bugs.
  - manicdee 6y ago
    Without consulting Stack Overflow, describe the “...” operator in Perl. As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. Clarity is far better than terse code that suffers from leaning toothpick syndrome.
    - chromatic 6y ago
      Without consulting Stack Overflow, describe the “...” operator in Perl. Does it count as a trick question if I implemented it?
    - lmm 6y ago
      > Without consulting Stack Overflow, describe the “...” operator in Perl. I don't know Perl. But I'm prepared to do that exercise for APL if you want. > As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
- deleted 6y ago
  [deleted]
- dragonwriter 6y ago
  I've yet to see 1,000 (or even 100, and rarely 10) lines of code doing what could be done in a 1 liner that is both clear and correct, and generally the more verbose, the less clear and the less correct it is. Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.
  - TheOtherHobbes 6y ago
    It's not line count, it's the dot product of line count and conceptual clarity. There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be. It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
    - dragonwriter 6y ago
      > It's not line count, it's the dot product of line count and conceptual clarity. In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related. Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.
- balladeer 6y ago
  Shorter code block doesn't mean unclear code. Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.

stanfordkid 6y ago

It applies to technology organizations though. I think being a smart engineer is very important when making architectural decisions -- but this is not always the bulk of the actual work. Lazy people tend to want to minimize total effort of the organization too.

MAJwlAL 6y ago

Typical downvotes: "Hacker" "News", a lot of whom think they are in the "smart and lazy" category, feels that their identity is threatened. Do you all think that Knuth was lazy, too? Delusion.

skrebbel 6y ago
do you make a new account for every comment somehow?