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.
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,
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
or or rather than 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#addto....