Hacker News new | past | comments | ask | show | jobs | submit login

Long-time Python dev here, recently started picking up Perl (both 5 and 6).

As with anything, learning another language will give you insight into how things _could_ be done, and you'll pick up a new perspective on programming.

More concretely, I've been liking perl because it's much more expressive than python, especially when writing small unix-y programs or scripts to control the machine.

And of course, sometimes it's just nice to have a variety of tools in your toolbox. We may as well ask whats the reason for learning Python when $LANGUAGE exists. The answer is always going to be some variant on "just because".




I'm not sure I agree that that there is clear winner in expressivity between Perl and Python. In Perl dealing with nested data structures feels really awkward. And Python's list and dictionary comprehensions and generator expression are very handy and highly expressive. Anonymous functions are much more pleasant in Perl than in Python. The added flexibility in placing 'if' and 'while' in Perl is nice sometimes, but I don't think it is a huge advantage.

Going over this (personal) list made me realized I'd probably like Perl 6 better than either Perl 5 or Python...


"more expressive" is often a slippery slope to "I can't read and understand what I wrote 3 months ago"

We read code more than we write it, so optimizing for typing time vs reading time is just losing the war to win the battle IMHO.


I think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stated in more meaningful ways.

    do_the_thing() if $is_ok;

    warn_the_user() unless $is_ok;
The if/unless pair, along with the ability to put conditionals either before or after the statement to execute, is just one example of Perl's ability to be very readable.


If we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.


Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done.

These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.


> These expressions with the conditionals on the end are supposed to reflect English phrasing.

But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing.

Do most programmers even have English as a first language?

I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.


From DougWebb, explaining why this would be a good thing to do.

>> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent.

We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.


I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'.

Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.


When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that.

If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.


Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date.

If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.


Everyone already knows what `if x then y` means, why is there a need for `y if x`? They're both as clear


It's actually "if x { y }" in Perl rather than "if x then y". This favours blocks of multiple expressions whereas "y if x" is good for a simple single expression.

A lot of the Perl branching and looping directives provide both methods so you can choose what you prefer.

Having both ways is great for the Perl one-liners :

    cat file | perl -e 'while (<>) {next if /^SKIP /; print if /<fancy regex>/;}'


If all someone wants to express to a reader is literally `if x then y` then `y if x` doesn't really help.

But we typically don't write utterly trivial one-liners with single letter names for conditions and actions.

In actual programming there are times when it's more like a series of lines, each of which is something akin to `if some-expression-that's-so-much-longer-than-a-single-letter-that-you-start-to-consider-factoring-it-out-in-to-another-variable-or-function then some-function-or-flow-control`.

And when that happens there are times where by far the most important thing a writer wants to first bring to the attention of a reader (eg themselves, later) is some-function-or-flow-control.

Sticking with made-up examples for a moment, there's:

  if long-complex-conditional----that-you-might-start-to-read-thru-in-an-attempt-to-understand-the-code-you're-reading---is-true then blow-rocket-up
vs

  blow-rocket-up if long-complex-conditional----that-you-don't-need-to-read-and-understand-to-understand-that-the-rocket-will-blow-up-if-it's-true----is-true
Or it takes me I estimate less than a second to know the gist of the overall control flow of this fragment from a recent Advent of Code entry[1]:

  next unless (() = /[aeiou]/g) >= 3;
  next unless /(.)\1/;
  next if /ab|cd|pq|xy/;

  $count++;
I can immediately see that it increments `$count` unless it bails out of the containing loop (`next`s) due to any of several (complicated looking) conditions.

In contrast, it might well take me more than a second to figure that out if they'd written:

  unless (() = /[aeiou]/g) >= 3 { next } ;
  unless /(.)\1/ { next };
  if /ab|cd|pq|xy/ { next};

  $count++;
While these examples are pretty weak, I have hope that they might at least give you pause for thought. If you don't see anything going on here worth even thinking about, or more importantly seriously reflecting on, well, at least I tried. And if you're a trained linguist and/or able to quote science to refute what other scientists are finding in recent studies[2], please quote away. :)

[1] https://www.reddit.com/r/adventofcode/comments/3viazx/day_5_...

[2] http://www.infosun.fim.uni-passau.de/cl/publications/docs/SK...


While I agree with you that they are not more readable, there are some other notable cases like that in the language, for example:

map { row => $_ } $db->get_rows


This is harder to parse in my mind than:

  if is_ok:
    do_the_thing()
  else:
    warn_the_user()
In that you can see more or less visually what the intent is rather than having to mentally parse the text. But perhaps that's just personal taste.

IMHO, expressiveness and conciseness are largely the same idea because when you talk about the former, you mean being able to bang out an idea in fewer lines of code yielding the latter.

Having a complex grammar and a myriad of ways to do the same thing seems very neat, but in the end the productivity gained in the writing, you waste several times in the reading, so it ends up being a net loss.

But Perl lost the dynamic language wars a long time ago -- I think perhaps some of the flavor got picked up in Ruby?

And having a language read like English is IMO, a bad idea -- English is very ambiguous in many cases -- mimicking this in your programming language would be a bad idea indeed.


It's precisely a slippery slope argument[1], which is generally much debatable.

Perl somewhat indulged the nix culture tendency to write extremely concise and cryptic one-liners, but* this does not mean that verbosity is good and expressiveness is bad.

[1] https://en.wikipedia.org/wiki/Slippery_slope




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: