|
in reply to Perl oddities
I've always been annoyed that you can't say:
if ($condition)
do_something();
The lame "Perl is saving you from nested elses"
rationale for this doesn't wash. Since when is
Perl a bondage and discipline language?
I often have written:
do_something() if $condition;
, which is less clear to me, to avoid taking
up four lines of screen/brain space with:
if ($condition)
{
do_something();
}
|
Re^2: Perl oddities
by TimToady (Parson) on Mar 01, 2005 at 20:55 UTC
|
Actually, I think C made the wrong choice here. It's not the braces that are being redundant, but the parentheses!
The parens are there only to avoid syntactic ambiguity if the following statement isn't a block. So the parens are what Perl 6 lets you get rid of:
if $condition { do_something() }
In fact, the braces are much more important in Perl 6 because they almost always indicate a closure, or at least a potential closure. That's important because the braces indicate delayed evaluation. A closure is treated as an argument to the control construct, so you could also write the above
as:
statement:<if>($condition, { do_something() });
But the converse is also true, that if you define your
own statement:<foo> with the same signature,
you can call it as:
foo $condition { do_something() }
just as if it were a built-in control construct. To do this in Perl 5 requires chewing gum and bailing wire, plus assorted smoke and mirrors.
| [reply]
[d/l]
[select] |
|
|
I'm not going to argue the logic of this. Being able to create a brand new language without making my jaw tired, running out of wire and having to go back to the store to get more, and in a non-smoking city ... that is great.
The fact is that most of the more popular languages use those parens. Whether your history is C/C++, Java, Perl5, or others which I've probably forgotten (I don't remember enough Pascal or Fortran to print out "hello world" - whether they do or not, I can't recall, but I'm not sure they quite qualify among the more popular languages, at least not from the perspective of those who would use Perl6), you're used to it. While it may not be intuitively natural for a human being to put parens around their conditional, it has been trained into a large majority of programmers to do it, even if that is against our nature.
Sometimes, bad choices are propogated to get over the inertia of the results of those choices. Rather than spending time retraining in the revolutionary new pattern of behaviour (I'd use the word "paradigm", but I think that word has lost all meaning), we stick to the tried-and-true-more-or-less. It helps languages, such as Java or C#, take off, because there is less retraining involved.
The trade-off here is that this may indeed be a revolution in language design. But it will delay the adoption of Perl6 (I think I've read something in the Apocalypses where this has been conceded already), possibly (although hopefully not) to the point where it just cannot acheive critical mass.
Another problem is for those of us who have to deal with multiple languages. I'm doing mostly perl5 right now, but I am still responsible for some C++ code (a couple KLOC), some shell scripts (probably about a dozen KLOC - ugh!), and have input into some Java code design issues. Yet another pattern will mess me up for a while - I can imagine that a number of people will just be too busy to pick up another language, especially one that has not (yet) hit critical mass, making it just a bit more difficult to acheive that critical mass. I'm not sure if I'll fall into this group or not yet.
I'm not saying that perl6 in general (or making parens optional in specific) is a bad idea. Someone has to come up with the revolutions every once in a while if we're ever going to get to that AI which just does what we ask it, without having to do all the drudgery of actually coding. It's just a risk. Whether good or bad, only time will tell.
Perl6 has, from what little I've read, so many time savers here and there - taken one at a time, most are pretty minor. Taken all together, it's pretty daunting. In some ways, renaming it away from "perl" may have been a good idea, so that no one thinks about it like perl. ;-) I think that perl6 shares less in common with perl5 than C++ shares with C ;-)
| [reply] |
|
|
If you don't like leaving off the parens, then don't. They are becoming optional, not illegal.
I'm not actually certain that you misunderstood that. I feel a bit like you've talked all around the point but I'm left guessing what your primary point was. But it sure feels like you got the impression that
if( CONDITION ) {
CODE
}
would no longer be supported in Perl 6.
So if that wasn't your premise, I apologize for not getting your point.
In any case, I suspect that most people won't be dropping the parens much -- based on my impression that most people don't currently drop the optional parens from
STATEMENT if CONDITION;
(like I usually do) and my agreement with you that dropping the former parens will be rather jarring in relation to similar languages (both Perl5 and non-Perl languages).
| [reply]
[d/l]
[select] |
|
|
|
|
| |
|
|
|
Re^2: Perl oddities
by DentArthurDent (Monk) on Mar 01, 2005 at 16:16 UTC
|
if ($condition) {
do_something();
}
A couple of things:
1. I've found that the braceless if can slow me down when reading C code. I have to remember that the next command is the thing that's done.
2. Cuddling the braces around their control statements saves a lot of whitespace without much loss of readability. Consider the following extension of my suggestion above:
if ($condition) {
do_something();
} else {
if ($another_condition) {
do_something_else();
} else {
do_yet_a_third_thing();
}
}
Just my $0.02
----
My mission: To boldy split infinitives that have never been split before!
| [reply]
[d/l]
[select] |
Re^2: Perl oddities
by dragonchild (Archbishop) on Mar 01, 2005 at 16:34 UTC
|
Which is more important - do_something() or $condition? The important bit should be left-most in indentation. I have often found
if (really_long_and_boring_condition)
do_something_useful()
to be much harder to read in C. Plus, people seem to feel that just cause you don't have braces means you don't have to follow proper indentation practices. (Not that braces always help, but it allows me to bounce on % in (g)vi(m).)
Personally, I prefer the following alternatives:
do_something_useful()
if really_long_and_boring_condition;
# Or ...
really_long_and_boring_condition
&& do_something_useful();
Depending on which is more important to understanding the program's flow.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply]
[d/l]
[select] |
|
|
I would argue that if the condition is "really long and boring", then it is *more* important to have braces and whitespace so it is easier to see where the actual action being taken is at a glance. The only one you mention that could work for me is:
do_something_useful()
if really_long_and_boring_condition;
Unfortunately, that's at the expense of putting the cart before the horse IMHO. The action doesn't matter if the condition is not satisfied.
----
My mission: To boldy split infinitives that have never been split before!
| [reply]
[d/l] |
|
|
When I see "die if (long && complicated condition)" I know that I can stop reading the condition, because it's an error check and therefore probably not interesting to me. Or, if it says "$name = $1 if /long and complicated regex/;" then I can skip over the regex because I know what it's doing.
| [reply] |
Re^2: Perl oddities
by eric256 (Parson) on Mar 01, 2005 at 15:35 UTC
|
if ($condition) { do_something(); }
Not the same, but its not four lines! ;)
| [reply]
[d/l] |
|
|
