There's a principle in programming (and elsewhere) that's often called DRY, for "Don't Repeat Yourself". The idea is that you should specify everything exactly once, because then you only have to change it in one place. Most programming languages, and most human languages, make this challenging.
Certain programming languages make this easier by allowing you to do all sorts of evil high-level mathematical tricks (I'm looking at you, Haskell and SML/NJ). And it's, y'know, cute. But I notice one thing in particular about the results of actually doing this.
It's dense. Absolutely every line is full of meaning. Looking at a page of the stuff is exhausting. There's a reason we don't write newspapers that way.
Books and newspaper articles are meant to be readable. So they go over facts in slightly different ways, add some fluff, make sure there's plenty of whitespace... They add a bunch of simple repetition, so it's not too awful to read.
What interests me most about this is that the dense, short, DRY-style text is much, much better to work out ideas in, at least as a programmer. Things change in one place only, you can see a much larger chunk of the total program, you can keep more in your head, once you've (slowly) absorbed it...
But almost nobody writes like that. At least for programmers, a lot of the problem is that it looks like a lot less work because it's so short. And in a discipline where it's very, very hard to measure actual ability or performance, people use a lot of bad metrics. The simplest is, "look how many lines I wrote!"
So you see people bragging, "I wrote a 15,000-line program!", but only rarely, "I wrote an 800-line program that does the same thing as his 15,000-line program!" And if there weren't a huge program to compare to, you wouldn't hear it at all. Rarely, in a few specific scripting languages, you'll see boasts that go, "look how much I got done in fifteen lines!" or something like that. But usually it's Perl, it looks like line noise, and nobody will ever be able to read it or modify it again :-)
The closest equivalent I know is math -- optics books, for instance, are full of one-line differential equations that you could spend months figuring out all the applications of. The Fundamental Theorem of Calculus turns out to be way more complicated (and useful) than it looks. Multivariate Calculus is full of concepts that require either a large chapter of text or three short equations to explain.
And few people work densely in that, come to think of it. The only examples I can think of are extensive proofs. I wonder if mathematicians would be more or less productive if they worked more purely in such things.
Something I'm curious about, after reading too much Paul Graham... Do software startups write much denser code? I know Paul Graham himself did -- the stuff he prefers with procedural macros is very similar to a lot of the dense, code-passing-heavy ruby code that I'm writing. But do startups, where impressing people matters less, do more of that?