6 ms·

I first looked at perl last week and also shared your sentiment. At first when I saw perl I was aghast. The "ugly" $%@ syntax seemed pointless and unreadable. T

I first looked at perl last week and also shared your sentiment. At first when I saw perl I was aghast. The "ugly" $%@ syntax seemed pointless and unreadable. Then I decided to take a look at a non-beginner book, Intermediate Perl http://it-ebooks.info/book/879/ http://it-ebooks.info/book/879/. I was surprised and excited 50 pages in because I realized that Perl had a wealth of tricks , and that that "ugly" $%@ syntax actually had some cool repercussions. The other thing I noticed was that Perl's flexibility led to the ability to write code that was closer to how I would structure the command grammatically, for instance, "print x if x>5." I'm looking forward to learning perl further.

Mithaldu 13y ago
Let me point out http://perl-tutorial.org http://perl-tutorial.org because most books you'll find by simply googling are terribly outdated and teach, plainly put, how to write shitty perl. Modern Perl and Ovid's Beginning Perl (not the older Beginning Perl) are excellent books to learn from. Also a note about the sigil: Get a decent syntax highlighting set up for your editor and you'll quickly realize how nice it is to have functions, variables and different variable types colored differently.
bonemachine 13y ago
Unfortunately -- and this is one of the many "banana peels" in Perl 5 -- even a simple statement like print x if x > 5 is problematic in p5 for a whole bunch of reasons: (1) At a bare minimum, what you really need to say is: print "$x\n" if $x > 5; That extra "\n" is a definite turn-off to a lot of people when the get their very first look at Perl. Really, the default these days should be more "say"-like. Of course, "say" is there as of 5.10 if you know where to look for it, and you go out of your way to enable it: use feature 'say'; say $x if $x > 5; (2) In "modern", better practice, production-quality Perl you pretty much have to either hedge every comparison op with a check for defined-ness: use feature 'say'; say $x if defined $x && $x > 5; in order to head off an unsightly warning about $x not being initialized: Use of uninitialized value $x in numeric gt (>) at print-if.pl line 5. or add even more boilerplate to suppress the warning: use feature 'say'; { no warnings 'uninitialized'; print $x if $x > 5; } or be very attentive about how $x can mutate once it's gotten passed whatever validations you're imposing on it before it enters your scope -- via e.g. Params::Validate, Method::Signatures, provided you know these tools exist and are up to speed and hip as to how to use them effectively. (Yes, I know that in some contexts, the warning on 'uninitialized' can be very useful. But my point is, most of the time, and especially for novices, it's more of a misfeature). (3) We shouldn't gloss over the fact that the magical pseudo-grammatical construction the "infix" if syntax provides is itself problematic in many ways. In the current example, it simply isn't clear -- until you've become very comfortable with the language! -- if the original statement say $x if $x > 5; is or is not equivalent to the very similar construction $foo = $x if $x > 5; say $foo This is because it is by no means obvious as to which of the more "active" parts of the original expression -- either the "verb" (print) or the conditional (if) -- takes precedence. And unfortunately, it's not only possible, but terribly easy to "whip up" fare more volatile constructions like this in Perl 5. Various on this theme -- gotchas about print, conditionals, and complex "if/unless" constructions -- were of course given ample treatment in Perl Better Practices, to the point where (I believe) that Damian pretty much eschews "trailing" if/unless constructions altogether. (4) Lastly, it's sad to say that for all the complains of Python having too many safety belts and what not, it completely nails the hidden complexity management issues embedded in such a simple construct like Perl's "print-if" idiom. In Python, basically the only sensible way to achieve the original desired result is to do this: if x > 5: print x Perfectly clear, completely unambiguous, and basically impossible to screw up.
- kbenson 13y ago
  This is because it is by no means obvious as to which of the more "active" parts of the original expression Isn't it? If someone told you, really you to do just that, would you actually have a problem carrying out that command given a way to print something, a container, and a value to check against the container contents? Also, here's me preference: say $x if $x and $x > 5; Need to catch zero? say $x if defined $x and $x == 0;
  - Mithaldu 13y ago
    Personally i find all of these forms weird. In a one-liner you wouldn't care, and in a full program the inputs would be validated earlier and separately with useful error messages.
    - kbenson 13y ago
      Here's my use case for most post conditionals: for my $item ( @items ) { # Weed out the things we don't want to process next unless $item; next unless $item->{foo} < 3; next if $item->{bar} < 2 and $item->{baz} =~ /quux/i; # Yep, these are good for processing $item->{othername} //= "$item->{foo} - $item->{baz}"; process( $item ); } Could that be done using maps and greps, and even be faster? Sure. Would it be harder to reason about and add documentation to? Probably. Additionally, I use them for parameter verification in subs: sub foo { my ($cowbell,%attrs) = @_; die "Needs moar cowbell!" unless $cowbell; die "Invalid color!" unless $attrs{color}//'' =~ /\A(bronze|silver)\Z/i; # blah } P.S. That's not to say I don't love a good map and grep combo, I do. After a certain point of craziness I convert to a loop and document a bit. I tried to add enough items to the loop that it would be a cumbersome map and grep.
  - bonemachine 13y ago
    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.

Mithaldu 13y ago

Let me point out http://perl-tutorial.org http://perl-tutorial.org because most books you'll find by simply googling are terribly outdated and teach, plainly put, how to write shitty perl. Modern Perl and Ovid's Beginning Perl (not the older Beginning Perl) are excellent books to learn from. Also a note about the sigil: Get a decent syntax highlighting set up for your editor and you'll quickly realize how nice it is to have functions, variables and different variable types colored differently.

bonemachine 13y ago

Unfortunately -- and this is one of the many "banana peels" in Perl 5 -- even a simple statement like print x if x > 5 is problematic in p5 for a whole bunch of reasons: (1) At a bare minimum, what you really need to say is: print "$x\n" if $x > 5; That extra "\n" is a definite turn-off to a lot of people when the get their very first look at Perl. Really, the default these days should be more "say"-like. Of course, "say" is there as of 5.10 if you know where to look for it, and you go out of your way to enable it: use feature 'say'; say $x if $x > 5; (2) In "modern", better practice, production-quality Perl you pretty much have to either hedge every comparison op with a check for defined-ness: use feature 'say'; say $x if defined $x && $x > 5; in order to head off an unsightly warning about $x not being initialized: Use of uninitialized value $x in numeric gt (>) at print-if.pl line 5. or add even more boilerplate to suppress the warning: use feature 'say'; { no warnings 'uninitialized'; print $x if $x > 5; } or be very attentive about how $x can mutate once it's gotten passed whatever validations you're imposing on it before it enters your scope -- via e.g. Params::Validate, Method::Signatures, provided you know these tools exist and are up to speed and hip as to how to use them effectively. (Yes, I know that in some contexts, the warning on 'uninitialized' can be very useful. But my point is, most of the time, and especially for novices, it's more of a misfeature). (3) We shouldn't gloss over the fact that the magical pseudo-grammatical construction the "infix" if syntax provides is itself problematic in many ways. In the current example, it simply isn't clear -- until you've become very comfortable with the language! -- if the original statement say $x if $x > 5; is or is not equivalent to the very similar construction $foo = $x if $x > 5; say $foo This is because it is by no means obvious as to which of the more "active" parts of the original expression -- either the "verb" (print) or the conditional (if) -- takes precedence. And unfortunately, it's not only possible, but terribly easy to "whip up" fare more volatile constructions like this in Perl 5. Various on this theme -- gotchas about print, conditionals, and complex "if/unless" constructions -- were of course given ample treatment in Perl Better Practices, to the point where (I believe) that Damian pretty much eschews "trailing" if/unless constructions altogether. (4) Lastly, it's sad to say that for all the complains of Python having too many safety belts and what not, it completely nails the hidden complexity management issues embedded in such a simple construct like Perl's "print-if" idiom. In Python, basically the only sensible way to achieve the original desired result is to do this: if x > 5: print x Perfectly clear, completely unambiguous, and basically impossible to screw up.

kbenson 13y ago
This is because it is by no means obvious as to which of the more "active" parts of the original expression Isn't it? If someone told you, really you to do just that, would you actually have a problem carrying out that command given a way to print something, a container, and a value to check against the container contents? Also, here's me preference: say $x if $x and $x > 5; Need to catch zero? say $x if defined $x and $x == 0;
- Mithaldu 13y ago
  Personally i find all of these forms weird. In a one-liner you wouldn't care, and in a full program the inputs would be validated earlier and separately with useful error messages.
  - kbenson 13y ago
    Here's my use case for most post conditionals: for my $item ( @items ) { # Weed out the things we don't want to process next unless $item; next unless $item->{foo} < 3; next if $item->{bar} < 2 and $item->{baz} =~ /quux/i; # Yep, these are good for processing $item->{othername} //= "$item->{foo} - $item->{baz}"; process( $item ); } Could that be done using maps and greps, and even be faster? Sure. Would it be harder to reason about and add documentation to? Probably. Additionally, I use them for parameter verification in subs: sub foo { my ($cowbell,%attrs) = @_; die "Needs moar cowbell!" unless $cowbell; die "Invalid color!" unless $attrs{color}//'' =~ /\A(bronze|silver)\Z/i; # blah } P.S. That's not to say I don't love a good map and grep combo, I do. After a certain point of craziness I convert to a loop and document a bit. I tried to add enough items to the loop that it would be a cumbersome map and grep.
- bonemachine 13y ago
  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.