Programming quotes

The point of the analogy is that both metrics are, fundamentally, useless. A 787 (unloaded) weighs about 175 tons. Does this mean that putting 175 tons of material at the end of the assembly line corresponds to the complete and proper assembly of a 787? Nope. There are other far more useful measures: does it look right, is it fitted correctly, does it pass QA (testing), is it composed of the correct pieces or just things that resemble them?

In software, LOC is, itself, a useless measure for progress for the same reason: It indicates nothing of value. I have inherited programs in the 10s and 100s of thousands of lines of code that I was able to reduce to less than 20% of their initial size without loss of capability, and generally with improved performance, stability, and maintainability. The right measures are around functionality and the other meaningful qualities (stability, security, testability, etc.).

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#addto....

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

That's not a definition of hubris that Aristotle would recognize. It's closer to Timē and Aretē.

I know it's not in keeping with the definition provided, but I like to interpret hubris in that context as "Believing that they are capable of writing software that is compatible with the second virtue, and that they can write it in a manner compatible with the first."

"They told me computers could only do arithmetic" is attributed to Grace Hopper.

I'm not the original commenter, but I have some:

"To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." – Grace Hopper

"Beyond basic mathematical aptitude, the difference between good programmers and great programmers is verbal ability." – Marissa Mayer

"I’ve always objected to doing anything over again if I had already done it once." – Grace Hopper

"The best icons are more like traffic signs than graphic illustrations." – Susan Kare

"You haven't mastered a tool until you understand when it should not be used." – Kelsey Hightower

"Some problems solve themselves if you are patient enough." – Jaana Dogan

"If too many users are wrong, it's probably your fault [..] If a bunch of people trip over the same thing, maybe it's not them. Maybe it's your product, or maybe it's just you." – Rachel Kroll

“Falling in love with code means falling in love with problem solving and being a part of a forever ongoing conversation.” - Kathryn Barrett

"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian

"Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made." - Karolina Szczur

"Sometimes it's better to leave something alone, to pause, and that's very true of programming." - Joyce Wheeler

"The purpose of software engineering is to control complexity, not to create it." - Dr. Pamela Zave