Explain why trading ease-of-writing for pain-of-reading is almost never a good idea

[mxstbr]

In Chapter 2 under Syntax you state

But we're trading ease-of-writing for pain-of-reading. This is not a good trade-off.

Without elaborating on why that's not a good trade-off. I think it'd help strengthen your argument to mention that any piece of code will be read much more often than written. That is because even when you write code, you have to read the surrounding code first to figure out where to even write code—so optimizing for ease-of-writing is really dumb since you're trading a bit of brain power now for a ton of brain power later.

[getify]

I made that statement (without backing it up there) because of these two sections in chapter 1, which I think adequately do back it up:

• Ch1 "Communication"
• Ch1 "Readability"

Specifically, some quotes:

You probably know by experience that an awful lot of your time spent "coding" is actually spent reading existing code. Very few of us are so privileged as to spend all or most of our time simply banging out all new code and never dealing with code that others (or our past selves) wrote.

It's widely estimated that developers spend 70% of code maintenance time on reading to understand it.

By having more code that's recognizable at a glance, and thus spending less time figuring out what the code is doing, our focus is freed up to think about the higher levels of program logic; this is the important stuff that most needs our attention anyway.

Do you still feel like that point is not made strongly enough across those two sections?

[mxstbr]

Oh yeah, good point, totally missed that! Closing!