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

On May 20, 2009, at 4:31 PM, pat eyler wrote:

> And you're on a mailing list full of people who find that the Ruby-way
> makes sense to them.  Don't knock it until you've tried it.

Just to kick in on this, I am a long-time Ruby programmer and Ruby is  
my favorite language.  I'd rather see full-strength macros than  
optional removal of 'end' keywords.  Having said that, let me admit I  
do not know how complex it would be to implement a solution in Ruby  
that optionally omits ends.  Some have argued, with what seem like  
plausible reasons, that it might be hard.  Others have attempted to  
rebut those reasons.  I agree with the calculus that if it is very  
difficult, it is not worth the benefit.  If it is easy, I'd like to be  
able to omit the 'end' statements.  They are line noise to me  
visually.  They just get in the way.

Another concern I have about this idea, though, is having essentially  
two forks of Ruby lexically speaking.  It's not much of an obstacle,  
but it is a minor difference that someone who comes along later to  
maintain your code might find confusing or off-putting.  And even  
though this particular change might be relatively minor, where do we  
draw the line?  What makes us decide whether another optional syntax  
change should be integrated into the language?  Even many small  
changes add up to a big difference in the way the code looks and the  
ease of maintainability.

I guess, however, this is no more serious than the positioning-of- 
brackets debate in C or even whether bracketless 'if' statements  
should ever be used, e.g.:

     if (foo)
         bar();
         baz();

The 'baz' function will execute regardless of the value of foo; this  
code is therefore visually confusing.

Macros, as I suggested above, would _really_ move in the direction of  
potential Ruby code that looks radically different.  But the payoff  
would be enormous expressive power, the ability to mold the language  
to suit the application domain in a very comprehensive way.  The  
removal of 'end', by contrast, would be only a slight improvement.  It  
would remove some visual noise and might attract a few Python  
programmers.  As I said, I think it's worth it if it's easy to  
implement, but not if it's more difficult.

steven