On May 28, 2009, at 5:20 PM, Eleanor McHugh wrote:

> On 28 May 2009, at 19:55, Juan Zanos wrote:
>> Terseness is a perfectly reasonable goal.  It's a corollary to  
>> Occam's Razer.
>> No?   If you're going to sacrifice conciseness you should have a  
>> good reason
>> for doing so.
>
> Occam's law applies to theory formation, not to literate exposition.  
> When writing code I'd rather err on the side of verbosity if that  
> expresses my model well to those who lack my implicit knowledge,  
> than terse and incomprehensible to anyone except myself.

I'd be careful about making such a narrow definition of the "law of
succinctness."   I'd also be careful about trying to twist the  
definition of
terse towards meaning incomprehensible.   A part of the definition of  
terse is
"easy to read."

You can choose whatever word you want to describe conciseness, but  
most of them
imply or directly state clearness or an ease of understanding not  
compromised
by beating around the bush or cluttering things up.  You can choose a  
near
synonym for concise that sometimes has a sense of impoliteness to make  
concise
look negative, but the fact is the computer doesn't care.

Trying to argue that longer is somehow inherently better doesn't make  
any
sense.  If you really feel that way then Ruby is a poor choice  
considering how
many wonderfully tedious languages there are just filled with  
redundancy and
unnecessary syntax.   How about Java's long winded forced naming  
conventions?
Or better yet how about C++ templates for readability? There's just a  
ton of
information about every last detail concerning types and all kinds of  
stuff and
lots of redundancy.  Certainly that is wonderfully readable compared  
to Ruby.

Seriously, if you want to argue some other point about implementation  
details
or some implication of a particular solution well then that's fair  
game.   But
you're not going to get anywhere arguing that longer is better or  
telling
people to go away and use some other language.