Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But I can look at most Python code and be able to understand what it does. With perl, I have to look up so much.

- Why is there a `1;` on a single line in the middle of this file?

- What is `$_`?

- This parallel execution manager doesn't actually seem to define what code needs to run in parallel in any specific way, how does this work?

- What is this BEGIN block at the start of this Perl file? Why is that necessary?

- What's going on with qx, qw, qq?

- What does chomp do when it's just on its own line, with no arguments given to it?





To be able to fully comprehend Perl (even without having to embrace it), one needs a fiddle.

Perl and some of Perl's quirks will make more sense once you realise that it is deeply rooted in UNIX command line utilities, UNIX conventions and some UNIX shell defaults, except when it is not, i.e.

  - What is `$_`?
$_ follows the spirit of shell variables (such as $*, $@, $! etc., heavily used in Korn, Bourne flavours but not the C flavours), but was repurposed or – more likely – picked from a pool of vacant characters with the help of a dice roll. Kind of like how ancient Egyptians built the pyramids with the help of sophisticated cranes and machinery and then vapourised their tools with high-particle beams to leave future generations guessing «how on Earth did they manage to do that». This is one of the main criticisms of Perl.

  - What is this BEGIN block at the start of this Perl file? Why is that necessary?
Perl started out as an improvement over «awk», and BEGIN is an awk construct where it is used frequently, e.g. awk 'BEGIN { IFS=":" } { … do something … }'

  - What does chomp do when it's just on its own line, with no arguments given to it?
It follows the standard convention of UNIX utilities that expect the input to come from the standard input stream (file descriptor 0 or <file-in in the shell) when no input file name has been specified. So, when no <FILE1> given to chomp, it chomps on the standard input.

Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.

$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.

BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.


> BEGIN? Take 60 seconds to read what it means.

Yes, that's exactly the problem: it's additional mental load you have to read up on.

Have 60 of those small oddities in a file, and suddenly you're spending an hour dealing with Perl quirks rather than actually debugging that obscure script a retired coworker wrote a decade ago. A 5-minute fix turned into a 65-minute fix, solely because of Perl.

Most programming languages use more-or-less the same constructs, and the few per-language oddities are usually fairly obvious from context. In practice this means someone familiar with any programming language will to a certain extent be able to read, debug, and patch small issues in code written in any other programming language. Perl's obscure and dense syntax makes this virtually impossible. Give a buggy Python script to a developer who daily-drives Javascript and they can probably fix it. Give a buggy Perl script to that same Javascript developer, and they probably have absolutely no clue what's going on.

In practice this turns Perl into technical debt. It has very few natural niches where it is genuinely the best, so experienced Perl developers are quite rare to have around. Any script written in Perl will most likely have to be read by someone who isn't an experienced Perl developer - which is significantly harder than a script written in just about any other language. The result is that any Perl scripts you have lying around are basically a grenade waiting to go off: they can't be maintained, so they should probably be replaced.


> what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't).

OK, I had never heard of the syntax, but in its own defense it does exactly what you'd guess, the same thing it does after an "if".

These are equivalent statements:

    preloop:
      if condition:
        do_more_stuff()
        goto preloop

    while condition:
      do_more_stuff()
and these are also equivalent:

    preloop:
      if condition:
        do_more_stuff()
        goto preloop
      else:
        wrap_it_ip()

    while condition:
      do_more_stuff()
    else:
      wrap_it_up()

It could've easily been defined that the else branch runs if the while condition never had a true value at all. In fact, I think that's more intuitive.

What are you trying to say? It is defined that way. And the example I provided above makes that completely explicit.

But here, from the official documentation:

> if the expression is false (which may be the first time it is tested) the suite of the else clause, if present, is executed and the loop terminates.

https://docs.python.org/3/reference/compound_stmts.html#the-...


It's not just a matter of "read the docs", though, because languages can differ in how many distinct concepts/constructs they employ. Python has gradually added more over the years but still I think is well short of Perl in this regard.

Given python’s love for string-leading sigils, the previous commenter should be quite comfortable with the idea of obscure single-letter operators that dictate the interpretation of the following tokens.

With regards to BEGIN

The only reason AWK needs a BEGIN is due to it's implied data loop. As far as I know perl has an explicit data loop and as such needs no BEGIN.

Oh god, perl has an implied data loop mode doesn't it. Sigh, now I am reading perl manpages to find out.

Update: of course it does, -n or -p


If you think that's bad, try learning python or a verbose language while not speaking english, all of these words like while, for, if, else, break are just gibberish and your code just reeks of some weird mish mash of broken english and broken <mother tongue>, I have a hypothesis that terseness favors universality, if you don't speak english, something like $_ is equal or easier to grasp, it honestly just looks like terse and weird math.

That was the idea of APL (and its successors like J and K) -- make programming a math notation rather than pretend to be a human language (generally English, but there have been programming languages with keywords in Chinese and Russian, among others).

You’re mad that you have to look up what keywords do in a programming language you aren’t familiar with? If you think Python is always clear, I can guarantee you (as someone with relatively expert grasp of Bash, Ruby, Go, and once long ago, Perl) that no, it isn’t always obvious.

Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.

And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.


> And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.

This is an amazing point that I haven't seen anyone else make about languages in this way.

As someone who got into the industry right after Perl's heyday and never learned or used it but learned programming from some former Perl power users, Perl has a pre-corporate/anarchic/punk feel about it that is completely opposite to something like Golang that feels like it was developed by a corporation, for a corporation. Perl is wacky, but it feels alive (the language itself, if not the community). By contrast, Golang feels dead, soulless.


Honestly, $_ and "what does a function do when I don't supply any arguments?" are really nice in Perl, and not that difficult to understand. I think a lot of languages could use a 'default variable'.

$_ was one of the things that put me off perl, because the same syntax meant different things depending on context.

The Pragmatic Programmers had just started praising Ruby, so I opted for the that over Perl, and just went with it ever since. Hated PHP and didn't like Python's whitespace thing. I never Ruby on Rails'd either. That said my first interactive website was effectively a hello world button with cgi/perl.

But trying to learn to code from reading other peoples perl scripts was way harder than the (then) newer language alternatives.

Now I'm over 50 none of that is nearly as important. I remember being young and strongly opininated, this vs. that - its just part of the journey, and the culture. It also explains the current FizzBuzz in CSS minimisation post. We do because we can, not necessarily because we should.




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

Search: