Re: semenatics of if/unless/while statement modifiers

On Nov 22, 2005, at 11:40 AM, Mathieu Bouchard wrote:

> Well, pretend you have a real one... and it'll behave like a real one.
>
> How pickier is it possible to get?

We're discussing language semantics here, 'picky' comes with the  
territory.

> It's not a matter of deciding what's the best overall type of loop and
> call all other ones ugly. Just pick the appropriate construct for the
> situation. The construct is the appropriate one if it doesn't make you
> jump through hoops.

I'd say that's the Perl philosophy--give the programmer every kind of  
construct imaginable, and trust that they'll pick the right ones.

The problem is that it bloats the language. Consider operators--there  
are a lot of operations that can naturally be expressed as infix  
operators. The Perl approach is to say well, let's have an operator  
for all of them, even if there are other ways to express the same  
thing, because what's important is not making the programmer jump  
through hoops. If they find it natural to express something as an  
operator, let them. The result is the Periodic Table of the  
Operators, <URL:http://www.ozonehouse.com/mark/blog/code/ 
PeriodicTable.html>, and a language that has 22 precedence levels.

I just don't have the brain space to deal with that amount of  
complexity. I think most people don't. That's one of the reasons why  
so many people think of Perl as a "write only" language--one  
programmer will pick up a dozen favorite structural idioms from the  
hundreds available, another will pick up a different dozen, and the  
two will be unable to read each other's code.

Then there's the effect it has on uptake of the language. C++ is  
another "give 'em everything and trust them to use it the right way"  
language, and as a result it takes 2-5 years to become proficient in  
it. And that's assuming you don't have to deal with code where  
someone has decided to make use of the ability to define your own  
operators and looping constructs...

Note that I'm not saying that this one addition of true post-test  
loops to Ruby would be a disaster. I'm just explaining why in  
general, syntactic features are not 'free', and giving programmers  
too much choice of how to express things can ultimately be bad for  
the language as a whole, and even bad for the programmers themselves.


mathew