Hacker News Reader

Comment by garrettdreyfus | Hacker News Reader

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/. 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.

View on HN

Let me point out 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.

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.

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;

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.

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.

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.

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.

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.

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)?

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?

BTW, as to your latter construct:

    say $x if defined $x and $x == 0;

Ya know, it'd be nicer if Perl 5 just had more sensible semantics to this whole "undef" business. For one thing, it's inherently confusing to conflate the semantics of "none of the above" with "not yet scoped". These are two entirely different states of being, yet this is exactly what Perl 5 does.

Really, something like None (as in Python), or Nil as in Perl 6 works a whole lot better. And whatever your magical "none of the above" symbol is called, it really should be == to anything else besides itself. Don't know about you, but

    $x = undef;
    print "boo!\n" if $x == 0;
    # boo!

smells way too much like PHP for my tastes.

Granted, Perl 5 was truly revolutionary in its time, and provided way better semantics for this particular corner case than any of its contemporaries. But it's 2013 and sadly, we know a whole lot better now.

Not knowing where uninitialized things can occur and prefer to put check for defined in every "if" is not the attitude to programming I'd support. Most of the parts of the code should operate on expected content. Undefinedness is very convenient but it is typically handled on the points where it matters, e.g. when you can not find the element in the hash, for example.

Rookie mistake missing those $. I think that python is different. One of the advantages of Perl for me is that it's more forgiving.This can suck sometimes especially if your trying to keep your code error proof. I've programmed for 3 years now. Its heavily impacted my thoughts. Often when giving directions I'll find myself self slipping into python pseudocode, "if you see the store turn right" or "while your on this road look for_." These are of course minor phrasing changes but not what I would have said before I knew python. Perl is refreshing because it seems to conform to how I think, not force me to think like it.

Slight correction: the "missing" $ were from the original post, and as I understood from the context at the time, were meant as pseudo-code.

Now, as to the fact that sigils basically don't bring all that much to Perl, are weird and distracting to newcomers and at the end of the day create as many problems as they solve... let's not go there, for now.

Reply on news.ycombinator.com