On May 28, 2009, at 9:39 AM, Caleb Clausen wrote:

> I feel that I did address this point adequately already, so it's
> annoying to see both you and Joshua Ballanco bring it up again,
> without even acknowledging that I had done so. Perhaps you don't agree
> with my points, but as you haven't tried to rebut them, I think it
> more likely that you did not read what I had to say at all.

I did not intend to offend by not explicitly calling you out. I did  
read that you had worked around this issue by allowing "end"s to be  
optional, and I had assumed that most others following this (now  
admittedly very long) thread would have as well. Again, I did not  
imply that tackling this issue was impossible (despite my poor choice  
of example script name). Indeed, I think I even showed how it would  
still be possible to do this even without "end".

I fear I did not make my point clearly enough: I prefer do...end to  
significant-whitespace. I think this is a commonly held preference,  
but by no means globally held. However, mixing and matching seems, to  
me, like a BAD idea. Why?

Well, if you're not going to enforce proper indenting when using  
do...end, what happens when someone takes working, but poorly  
formated, code from a do...end block and copy-pastes it into a block  
using indentation instead? You now have code that works in one place  
but not in the other. That is, with optional do...end/significant- 
whitespace, code that works in one part of a source file might NOT  
work in a different part, and the reason for this will be non-obvious.

How about this compromise: Fork Ruby, enforce significant-whitespace,  
and instead of writing a preprocessor that converts significant- 
whitespace into do...end form, write it to go the other way 'round.  
All (or most) of the gems/libraries out there would still be  
available, but now you could have a countable number of "Swuby" users  
to show the superiority of significant-whitespace.

- Josh