"You often hear about how important it is to write 'readable code'. Developers have pretty strong opinions about what makes code more readable. The more senior the developer, the stronger the opinion. But, have you ever stopped to think about what really makes code readable?"

So, his point is that a big vocabulary lets a writer feel good about what he is writing -- he feels he is saying exactly what he wants -- but his subtilty is lost on beginners.

There is this thing that happens -- an author can get mesmerized by his craft. He gets great satisfaction when he picks the right word, like he's playing sudoku. This is a vainity.

Yeah, reminds me of reading some Perl code. It seems that a lot of Perl programmers will go out of their way to write code in the least amount of lines as possible, and to hell if anyone but Perl gurus can actually read it. And the end result looks like modem line noise on a terminal. It's like prog rock bands who will play solos for 40 minutes, if for no other reason than to show off, thereby alienating everyone in the audience, except for the 1% who are also prog rock snobs. Note that I'm not dissing either Perl or prog rock, because I like both Just bitching about the excesses of both.

In his article, he says whether or not you should put code on one line or stretch it out to a few depends on who your audience is. I say that's horseshit. If there's two ways to write the code, you should always put it in the form that's easiest to read, especially since you never know who's going to be debugging your code 10 years from now. At least that way, even if experts are a bit irritated by the simplicity of it, you know everyone is going to be able to read it.