3 ms·

If someone told you, really you to do just that, The problem here is that's just one way (in linguistics: "voice") in which the statement can be parsed. Ano

If someone told you, really you to do just that, The problem here is that's just one way (in linguistics: "voice") in which the statement can be parsed. Another way is to look at it mathematically: print <expr> where expr := x if x > 5 which of course has an entirely different meaning. What compounds the difficulty is that in general it's really difficult to anticipate all of these syntactical corner cases through a careful, a priori study of the man pages, or any of the available introductory literature. The only time-effective way (for most people) to get up to speed in a new language is through practice. Supplemented of course through book & occasional man page study. But really the way most people learn is programming is "by doing." Which, sadly for Perl 5, means "by shooting yourself in the foot", in the prolonged early learning phase, for most people.

kbenson 13y ago
You mean this, from the perlsyn man page? Statement Modifiers Any simple statement may optionally be followed by a SINGLE modifier, just before the terminating semicolon (or block ending). The possible modifiers are: if EXPR unless EXPR while EXPR until EXPR when EXPR for LIST foreach LIST There are rules for how loosely and tightly different operators bind. Read the docs, and your questions will be answered. Ignoring the documentation does not make for a good argument.
- bonemachine 13y ago
  The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please? This has been observed with countless other technologies -- JavaScript, MySQL, MongoDB, etc. Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better. And interestingly: the very use case that started this whole thread statement IF isn't in your excerpt, above. Which means that new users are most likely to encounter it "experimentally", i.e. while debugging someone else's convoluted while/unless/last/goto loop. Of course, it's not that hard to "figure out." Implicitly, it refers to the issue of precedence, which is presumably detailed, uh, somewhere else. Which means a new user to the language has to either spend more pillow time reading, or more hair-pulling time watching their programs blow up unexpectantly before they "get the hang of it." Which has a lot to do with why newer programmers just aren't turning to Perl as much, these days.
  - kbenson 13y ago
    I urge you to read the first full sentence under the heading in the documentation I posted. The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive And I don't think you need to in order to assume the correct functioning of print $x if $x; As much as you may find it compelling to point towards it's possible interpretation as print( $x if $x ); I find that interpretation nonsensical, and anyone making any effort to learn how the language works or if not that, at least think about what it could mean and what it probably means will not be surprised. Perl tries to Do The Right Thing (DTRT) whenever possible, and with this principle in play, I think the meaning of this statement is very obvious. Even if we extend the statement to be somewhat more ambiguous, a bit of thinking about the problem makes it obvious what the right thing to do is, and it is indeed what Perl does: print $x, $y if $x; # OR print $x, $y if $y You can either interpret that as Perl does, or as: print( ($x), ($y if $x) ); # OR print( ($x), ($y if $y) ); Do you ever really want something like that? Is that useful to you, given that there are a few other ways of achieving that which are much less cumbersome ($y||$y)? The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please? It's almost comical that you are making this argument. One of Perl's strong points is that it's really easy for someone to pick up and start using, because it tries to DTRT, making it very easy for the beginner. Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better. When I mention Perl, I still hear people immediately jump out with "Oh, I remember I used Perl back in the day and it was real easy to whip up a little program to do what I wanted." I think what you are running into is that you have experience and expectations with other languages, and when Perl doesn't match those expectations, you blame Perl, rather than meeting it at it's own level. I suspect you don't do this as much with languages that appear radically different, such as Haskell and Lisp. If so, is that Perl's fault for following a different path, or yours for failing to use it appropriately?

kbenson 13y ago

You mean this, from the perlsyn man page? Statement Modifiers Any simple statement may optionally be followed by a SINGLE modifier, just before the terminating semicolon (or block ending). The possible modifiers are: if EXPR unless EXPR while EXPR until EXPR when EXPR for LIST foreach LIST There are rules for how loosely and tightly different operators bind. Read the docs, and your questions will be answered. Ignoring the documentation does not make for a good argument.

bonemachine 13y ago
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please? This has been observed with countless other technologies -- JavaScript, MySQL, MongoDB, etc. Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better. And interestingly: the very use case that started this whole thread statement IF isn't in your excerpt, above. Which means that new users are most likely to encounter it "experimentally", i.e. while debugging someone else's convoluted while/unless/last/goto loop. Of course, it's not that hard to "figure out." Implicitly, it refers to the issue of precedence, which is presumably detailed, uh, somewhere else. Which means a new user to the language has to either spend more pillow time reading, or more hair-pulling time watching their programs blow up unexpectantly before they "get the hang of it." Which has a lot to do with why newer programmers just aren't turning to Perl as much, these days.
- kbenson 13y ago
  I urge you to read the first full sentence under the heading in the documentation I posted. The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive And I don't think you need to in order to assume the correct functioning of print $x if $x; As much as you may find it compelling to point towards it's possible interpretation as print( $x if $x ); I find that interpretation nonsensical, and anyone making any effort to learn how the language works or if not that, at least think about what it could mean and what it probably means will not be surprised. Perl tries to Do The Right Thing (DTRT) whenever possible, and with this principle in play, I think the meaning of this statement is very obvious. Even if we extend the statement to be somewhat more ambiguous, a bit of thinking about the problem makes it obvious what the right thing to do is, and it is indeed what Perl does: print $x, $y if $x; # OR print $x, $y if $y You can either interpret that as Perl does, or as: print( ($x), ($y if $x) ); # OR print( ($x), ($y if $y) ); Do you ever really want something like that? Is that useful to you, given that there are a few other ways of achieving that which are much less cumbersome ($y||$y)? The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please? It's almost comical that you are making this argument. One of Perl's strong points is that it's really easy for someone to pick up and start using, because it tries to DTRT, making it very easy for the beginner. Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better. When I mention Perl, I still hear people immediately jump out with "Oh, I remember I used Perl back in the day and it was real easy to whip up a little program to do what I wanted." I think what you are running into is that you have experience and expectations with other languages, and when Perl doesn't match those expectations, you blame Perl, rather than meeting it at it's own level. I suspect you don't do this as much with languages that appear radically different, such as Haskell and Lisp. If so, is that Perl's fault for following a different path, or yours for failing to use it appropriately?