On 28 May 2009, at 15:06, Juan Zanos wrote:
> As I've watched this debate unfold I've watched the stronger  
> criticisms fall
> apart.  The strongest type of criticism would be that it can't be  
> done, or that
> it's too hard to be done.  But the impossible examples seem to be  
> defeated
> fairly easily.   Moreover, the solutions are backward compatible to  
> existing
> Ruby.

Some cases have been presented elsewhere in this thread where the  
pythonic indentation would fall flat: specifically for expressions of  
the form

a = case x
   when...
   when...
   when...
end if y

It's not a common formulation in this form, but it highlights the  
problem of using significant whitespace as an expression delimiter in  
expression-based languages. Were there a way to solve this ambiguity  
elegantly then there would be a case in favour of introducing pythonic  
indentation, but until then this would either introduce an unnecessary  
limitation on the things that can be expressed in ruby or lead to a  
considerably more complicated lexer that might have other implications.

> Now when I look at this latest example I see some ordinary code  
> that's 44 lines
> long.  With the pythonic scheme it looks like it's only 35 lines  
> long.  I find
> it difficult to convince myself that it's a good idea to make code  
> 25% larger
> just to preserve some ends of dubious value.
>
> I suppose I could try to come up with some nonsense argument that  
> 'end' makes
> everything more readable.  But that would just be prejudice.  The  
> pythonic
> example is trivially easy to read.  It can't just be me.  There  
> seems to be no
> shortage of Python folk who have no problem.   Objectively, the ends  
> just take
> up a whole lot of space.

Begin..end indicates explicitly that a series of expressions is  
contained between these statements and that their return value is  
available to use as part of a more complex expression which may have  
modifiers, something of great value to some of us. Your experience  
might well be very different and this might not be a use case you  
commonly encounter, but please don't make the mistake of believing  
that your use case invalidates the utility of this language feature.  
Most of the code I work on takes this form and has perhaps a 10%  
density of 'end' statements, if that.

Admittedly when I've worked on Rails apps I've seen the 25%  
demonstrated in your quoted example frequently: to my mind that's a  
code smell suggesting that much of that code is boilerplate ripe for  
abstraction and meta-programming. Such an approach would bring the  
'end' density back down to an acceptable and useful level.

The real answer to this issue is to have a pythonic indentation pre- 
processor for those who find that of use, and to leave the core  
language syntax alone.


Ellie

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