3 ms·

It seems yours is the more widely-known phrasing of it, which however was not the original. According to [1], it comes from "The Elements of Programming Style",

It seems yours is the more widely-known phrasing of it, which however was not the original. According to [1], it comes from "The Elements of Programming Style", where it was worded the way it's quoted in the article. [1]: <https://github.com/dwmkerr/hacker-laws#kernighans-law https://github.com/dwmkerr/hacker-laws#kernighans-law>

kragen 6y ago
Hmm, I haven't read that book this millennium, but I had thought I first encountered the quote in The Practice of Programming. Which, I mean, I also haven't read this millennium, but when I did read it it was after The Elements of Programming Style. I guess I should check... It turns out that it is in The Elements of Programming Style, on the second page of Chapter 2, "Expression", in the second edition: Suppose that you were trying to teach a novice programmer how to count the blanks in a string. How would you do it? Surely not by this elegant but mystifying method [omitted] — instead you would say “Look at each character, and if it's a blank, count it.” Or, in PL/I, DECLARE TEXT CHARACTER(200) VARYING; GET LIST (TEXT); N = 0; DO I = 1 TO LENGTH(TEXT); IF SUBSTR(TEXT, I, 1) = ’ ’ THEN N = N + 1; END; PUT LIST (N); This too uses the built-in functions PL/I provides, but it uses them in a way that clarifies the method of solution, rather than obscuring it. Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I think this is, if anything, truer now than it was in 01978 when the book was published, even if not many of us have to deal with PL/I nowadays—thanks, in significant part, to Kernighan's efforts. And it's probably thanks in part to reading this book that today I would more likely write that as sum(1 if c == ' ' else 0 for c in text) or sum(1 for c in text if c == ' ') or (loop for c across text if (eq c #\space) sum 1) rather than sum(c == ' ' for c in text) which also works. Being too clever is what almost always trips me up in Forth. It's not so much the stack-effect bugs or the type errors themselves, although of course those require more care to avoid than in C; it's the constant temptation to bum the code down to something smaller and simpler by, for example, keeping more crap on the stack. I think I did manage to use Forth effectively and avoid being so clever in, for example, https://dercuano.github.io/notes/forth-assembling.html#addtoc_3 https://dercuano.github.io/notes/forth-assembling.html#addto....
keithalewis 6y ago
Ronalds Vilciņš did his homework. He also gives Stroustrup's original quote.

kragen 6y ago

Hmm, I haven't read that book this millennium, but I had thought I first encountered the quote in The Practice of Programming. Which, I mean, I also haven't read this millennium, but when I did read it it was after The Elements of Programming Style. I guess I should check... It turns out that it is in The Elements of Programming Style, on the second page of Chapter 2, "Expression", in the second edition: Suppose that you were trying to teach a novice programmer how to count the blanks in a string. How would you do it? Surely not by this elegant but mystifying method [omitted] — instead you would say “Look at each character, and if it's a blank, count it.” Or, in PL/I, DECLARE TEXT CHARACTER(200) VARYING; GET LIST (TEXT); N = 0; DO I = 1 TO LENGTH(TEXT); IF SUBSTR(TEXT, I, 1) = ’ ’ THEN N = N + 1; END; PUT LIST (N); This too uses the built-in functions PL/I provides, but it uses them in a way that clarifies the method of solution, rather than obscuring it. Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I think this is, if anything, truer now than it was in 01978 when the book was published, even if not many of us have to deal with PL/I nowadays—thanks, in significant part, to Kernighan's efforts. And it's probably thanks in part to reading this book that today I would more likely write that as sum(1 if c == ' ' else 0 for c in text) or sum(1 for c in text if c == ' ') or (loop for c across text if (eq c #\space) sum 1) rather than sum(c == ' ' for c in text) which also works. Being too clever is what almost always trips me up in Forth. It's not so much the stack-effect bugs or the type errors themselves, although of course those require more care to avoid than in C; it's the constant temptation to bum the code down to something smaller and simpler by, for example, keeping more crap on the stack. I think I did manage to use Forth effectively and avoid being so clever in, for example, https://dercuano.github.io/notes/forth-assembling.html#addtoc_3 https://dercuano.github.io/notes/forth-assembling.html#addto....

keithalewis 6y ago

Ronalds Vilciņš did his homework. He also gives Stroustrup's original quote.