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

On May 28, 2009, at 9:26 PM, James Britt wrote:

> Juan Zanos wrote:
>
>> Trying to argue that longer is somehow inherently better doesn't  
>> make any
>> sense.
>
> Same holds for the inverse. But no one has been arguing that longer  
> is inherently better.

Well, maybe we'll just have to agree to disagree on that one.  Shorter  
is better to the degree that nothing is harmed by doing so.  If  
significant indentation sufficiently harms something else then I agree  
that is important too.
>
>
> My point is that zero entropy and  maximal information is a poor  
> goal when targeting people, that some amount of redundancy reduces  
> errors and improves communication (again, for people).
There is a well known and written about principle of economy that  
applies universally to human languages.   If we're talking about  
shortening everything then I'd agree with you completely.   But when  
something is really common we alter the language to make it shorter.   
An entire line occupied only by the word 'end' is one of if not the  
most common line in Ruby.   That makes it a great candidate for  
applying a principle of economy.
>
> I do not have any objective way to say what, exactly, that is for a  
> programming language.  My own experience from working with  
> indentation sensitive languages is that the trade-offs do not always  
> sit well with me.   Nor does the verbosity of Java
The commonness of the occurrence is one key factor.  All those  
needless semicolons in Java, for example.
>
>
> My experience with Haskell has been much different than my attempts  
> at Python.  Maybe it's Haskell's emphasis on mathematical functions,  
> on using a format that employs (so it seems) a whole lot of equal  
> signs. The use of white space there feels much more natural than it  
> did for me with Python.  (I also think Haskell induces different  
> expectations about what things should look like. It would probably  
> feel wrong to use do/end for something that is essentially  
> mathematics.)
>
>
> The information provided by significant indentation,  while usable  
> (and possibly more efficient for some cases of human parsing),  
> introduces restrictions on how it may be used elsewhere, effectively  
> limiting how a writer expresses non-syntactical information in a  
> program.
Well that could be a good argument against.  I'm not familiar enough  
with such counter examples to say.  So far I've
been pretty impressed with what Caleb's tool can do.
>
>
> What puts me off so many discussions about code formatting is the  
> idea that code is first meant to provide instructions to a machine,  
> and ideas for people second.
>
> The "machines first" attitude may be the reason for so much cruft in  
> Java.  I'm sure GvR had "people first" in mind when opting for  
> significant indentation, but perhaps he viewed writing software as  
> primarily an exercise in generating code, less as writing a document  
> for other humans that is also machine readable.  That is, the goal  
> was highly-readable computer expressions, not machine-readable  
> people expressions.
I agree with you.  Java advocates I know will claim that static typing  
is worth the added redundancy and verbosity because it reduces the  
chance of type errors and provides structure.  They don't believe that  
you can have industrial strength applications without it.   Sound  
familiar?

My own guess is that static typing currently provides an efficiency  
advantage that isn't yet available in most dynamic languages.   
Actually, I've heard that Sun's JVM now throws away static type  
information anyway.   It would be interesting to know more about that.

I write way too much Java.  I've been pretty disappointed that it  
seems to be getting more verbose and less expressive for reason that  
at this point still don't make much sense to me.  JRuby is a breath of  
fresh air.