Re: Pythonic indentation (or: beating a dead horse)

On 28 May 2009, at 23:06, Juan Zanos wrote:
> 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."

As with most things in life, whether or not something is "easy to  
read" depends upon your frame of reference. What makes perfect sense  
to you today may not at a later date, and may never make sense to  
someone else. That's why I mentioned implicit knowledge, a commodity  
which is present in all skills and that by its nature is hard to  
transmit because those who possess it are largely unaware of its  
existence.

> 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.

No, the computer doesn't care and is quite happy to be programmed in  
its own binary language - just a stream of 1s and 0s. However the  
history of language design has been to move away from direct machine  
notation (which is tedious and error prone), co-opting syntactic and  
semantic features from natural languages. This makes good sense as  
code has to be designed and maintained by people who in general have a  
higher facility with natural language than they do with machine code.  
And one of the interesting things about natural language is that it's  
not indentation sensitive.

> Trying to argue that longer is somehow inherently better doesn't  
> make any
> sense.

You clearly haven't spent much time trying to maintain extremely terse  
C or you'd have quite a different perspective.

> 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.

There are two kinds of redundancy. That which comes from cut-and-paste  
and is a code smell, and that which exists as a structural safeguard.  
'end' is the latter kind of redundancy and whether you like it or not  
many of us find that supposed lack of conciseness to be a concise  
representation of block identity.

> 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.

And you're not going to get anywhere by acting as if significant  
indentation is a must-have for Ruby or any other language.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason