From: Steven Arnold Date: 2009-05-21T13:28:19+09:00 Subject: 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