not sure if i am saying the obvious here, but the reason that brevity is important is because it shows that you have the right abstractions. short code is a good indication that it's done right - you've found the best way to <i>express</i> the problem and so don't need to say so much handling the parts that you have not captured well.<p>if some languages are more verbose than others, then this can be for two reasons:<p>first, they may just need more typing to say the same thing. this is not, in my opinion, a problem.<p>second, they may lack ways of making abstractions that stop you from producing a good solution. that, in turn, leads to longer code (see above). this <i>is</i> a problem.<p>so "verbose languages" are not in themselves bad. the problem is languages that don't support easy / sufficient abstraction. and brevity is a quick n easy way of measuring this.<p>taking that further, and ignoring the practical issues, a strongly typed lisp might be more verbose if it required type annotations in some places. that wouldn't make it necessarily worse. in comparison, lisp without macros loses expressive power (in some vague sense) and so is worse (and gives longer code).
I'm not sure i agree with graham on this one. Certainly it's useful and necessary to keep some brevity, however his jab at design patterns is a schoolbook false opposite (if you don't like extreme brevity you must be an enterprise java programmer, seems to be his subtext). That, and some lengh/repetition is useful to the brain's pattern recognition, allowing simpler understanding of code. There is of course also a point where too much repetition leads to a "can't see the code for all the statements" situation.
Where exactly this point is is probably highly personal.