https://blogs.perl.org/users/dimitrios_kechagias/2022/11/per...

I still code in Perl a fair bit for work. One great improvement I have taken advantage of is subroutine arguments, rather than unpacking @_ at the head of each subroutine. It is much easier to tell what the sub expects, and if the caller passes the wrong number of args it is a compile time error.

The main draw for me is that regex is built into the syntax of the language, and not a library. If the task requires a lot of pattern matching and string manipulation and speed isn't that critical, I reach for Perl.

… others dislike the idea of $ sigils as “noun” markers and @ sigils to denote plurals but imo these features trick your brain into engaging these natural language concepts.

In contrast, I feel that Java is “heavy”, Python is “sciency” and so on.

The other distinctive aspect of perl is that it does not seek to constrain and block the coder. Strongly typed and opinionated languages (like Rust and Haskell) can be frustrating since they force you to code their way. That’s fine - it’s in the contract. perl is for when you just want a bag of tools to get the job done without becoming a wrestling match.

This flexibility also means that non standard code is easier to write in perl. The tool gets a bad reputation at the hands of poor coding practices. A higher level of trust and self-discipline is needed.

perl6 - now renamed to www.raku.org, continues the spirit with a cleaned up syntax and a lot more features in the core language

  for 1 .. 100 {
    when $_ %% (3 & 5) { say 'FizzBuzz'; }
    when $_ %% 3       { say 'Fizz'; }
    when $_ %% 5       { say 'Buzz'; }
    default            { .say; }
  }

... who won the IOCC 2 times! https://www.ioccc.org/winners.html#W

https://www.linkedin.com/pulse/18th-december-day-perl-progra...

Obfuscation coding contests, Perl golf tournaments to create the shortest feasible code for a specified function, and Perl-language poetry collections have all grown up as a result of Perl's versatility.

Your takeaway may well be that perl is not the kind of thing that your boss would like. My takeaway is that perl (and raku) is versatile and engenders a sense of -Ofun.

And this becomes a problem in teams.

I do somewhat miss perl, because perl and some libraries did some things better than later languages. You could express some ideas very concisely. Or, croak and carp only reporting functions crossing module or library boundaries in a stack trace (instead of some java teams complaining that the log aggregation refuses to collect 50kb+ sized stacktraces, not even exaggerating there).

Alternatives like python force you into a more maintainable style. Like, don't get me wrong, you can write unmaintainable code in any language, and python would be my language of choice to make a horrible non-understandable mess with the extensive meta programming capabilities.

But with perl, you kinda have to put in effort to stay on the simple path. If you leave that part, it quickly becomes very dark. And I know some of my co-workers.

I'll miss you qw//, but I was out-voted. :(

  qw/one two three/;

  <one two three>

It's telling that perl is/was absolutely functional at it's core -- a pidgin of bash and <proper programming>, if one might will.

  my $logger = -> $m { say $m; $m };
  my $add-five = -> $x { $x + 5 };
  my $add-five-and-log = $add-five o $logger;

  say $add-five-and-log(25); # Prints 25, then prints 30

Python makes quite a few things easier if only because of how "teachable" it is between colleagues, but the really useful tools that bear more in common with the human relationship with data as text-at-scale were part and parcel to the POSIX-likes. The biggest challenges I faced were getting IT to let me use Linux at work and convincing peers to try it.

With perl7 still being worked on, is it really a continuation or they're just branching off? I'm still not sure what's their relation to each other now. Why would one choose to use perl over raku or vice-versa?

Perl7 seems to be Perl5 with some changes to the defaults. They can't upgrade to Perl6 as that would be needlessly confusing. If foresight were perfect, Perl6 would have always been a different language name so Perl proper would continue without confusion. The problem was that they had no idea how hard it would be to make Perl6 and thus thought it would be ready in a few years (my understanding) and everyone would upgrade. Raku/Perl6 is SERIOUSLY COOL. I think it just needs a larger community and that's a chicken/egg problem.

Perl 6 was intended from the start to be the next major release of Perl (at various times, a replacement for a 5.10 or 5.12 or 5.14), and it was intended to have a backwards compatibility mode to run 5.8 (or 5.10 or 5.12) code in the same process, with full interoperability.

As time went by, that plan became less and less likely. Some people came up with the idea that Perl and P6 were "sister languages", both to have new major releases. I think this happened sometime around 2009 or so, maybe as early as 2007.

Also by 2011 or so, the P6 developers effectively scuttled the backwards compatibility plan and code written to that point, but I've argued that their plan to replace Parrot was a mistake enough here and elsewhere already. (Sometimes I wonder, now that MoarVM is older than Parrot was when Parrot was declared unsuitable, if they've achieved their promised speed and compatibility goals.)

This year I've written a fdisk replacement in perl, to make hybrid MBR+GPT for bootable media.

First, I wanted to check how they were made, but then I decided I wanted to programmatically write hybrid MBR in a way that's easier than gdisk and that offers more control that xorriso.

It's not complete yet, but the partition reading feature was already very helpful to understand the ins and out of the mfg59 layout that's so popular for optical media, and the final gpt tweaks should only take a few more days.

perl allowed me to write it very quickly and to make sure it will work reliably for the years to come.

But I’m also saying this while holding a sharp stick and slowly backing away. That is not the sort of thing I’d expect someone to write in Perl, and I’m experiencing an odd mix of “that’s amazing!” and “what on earth were you thinking, my friend?!”

Some people have an instinctual dislike of things they've been told it's fashionable to hate. I resent that, because all programming languages are interesting in their own ways.

> It sounds like quite the ambitious project that you’ve nearly got working. Cool!

Oh it's already working, it just needs more polish :)

Check https://github.com/csdvrx/hdisk if you're interested

Actually, I'll try to submit it!

> That is not the sort of thing I’d expect someone to write in Perl, and I’m experiencing an odd mix of “that’s amazing!” and “what on earth were you thinking, my friend?!”

I wanted to do it quickly :)

For decoding weird formats that mix little and big ending, I think perl unpack/unpack is the fastest way.

Also, for computing crc32, I didn't have to bother much :)

Huh, wonder if people who aren’t familiar with the subject saw “GPT” and thought you were going off into AI gibberish land?

If they don't know GPT is a type of partition table, I think their stereotypical dislike of perl is the least of their problems!

I've actually written a few Perl programs and I really did not enjoy the experience at all.

Its regex engine has good Unicode support, if you can figure out how to enable it. I'll give it that.

Perl was the first non-C language I wrote significant amounts of Unix code in. In particular, I wrote lots of web and server admin projects with it. I know Perl well enough to 1) appreciate why people still like using it, and 2) not want to use it myself.

And then when I learned this and that, the code started to be more concise, to the point of being impossible to understand for the author (me) after a week.

I liked it though and I realize that this is not Perl's fault but mine. Still, giving too much power to less experienced devs without having them unlock some kind of experience badge is dangerous :)

Bigots gonna bigot. Perl is an unorthodox language; Larry would probably prefer eclectic. It’s tough being the different kid. As paulg wrote, “The superficial demands of orthodoxy make it an inexpensive substitute for virtue. And that in turn is one of the reasons orthodoxy is so attractive to bad people. You could be a horrible person, and yet as long as you’re orthodox, you’re better than everyone who isn’t.”

Wow, interesting quote. I agree with it. We see such behaviour all the time in people.

Do you remember where you read it? Was it in one of his essays or tweets? I would like to read the original, with context, if any.

Whenever the Java troupe gets all excited about multi-line strings, or closures, or string interpolation (what nasty syntax!), it's my turn to laugh.

All in good spirits, of course.

They say junkyards have a sizeable choice of car parts, too.

The usual ghost town with tumbleweed on its streets.

It's the best format of reference I've seen for the times I'm asking myself what's the minimum version of Perl needed for this bit of code and what becomes available when ops upgrades the production server.

But here's a cool thing - in coding interviews for non-SWE roles (I'm in security), when they say 'pick any language', I go straight for Perl. Why? Because it's very forgiving when prototyping a solution quickly, has great data-structures without a lot of setup (auto-vivification!), built in grep and map features, etc.

The other good thing is that the interviewer probably won't know it and wouldn't be able to critique your solution ;-)

Number of breaking changes I have experienced in these 7 years? 0.

Number of times I've had any significant issues setting up a new deployment? 0.

It may not be as popular, but it certainly continues to work well.

If I write something that I plan to reuse or need again later, I will write it in perl

Never used it myself, just repeating what heard.

https://www.effectiveperlprogramming.com/category/perl/new-f...

It's not like Java/Go/Rust where you really have to wait for new syntax in the language.

I think maybe whoever thinks like this about Perl shouldn't have been using it in the first place because they needed something different, like a strongly typed language.

Php startet as a Perl framework. Ruby is direct reaction to Perls inability to evolve (Perl autobox is great. Why not in core). There is Python. I love Perl. Use it daily. I used Moose, mouse, any::mouse and was excited about p5-mop. But there is no traction in change. Also fact is Perl has a bad image and Perl gets patched out of all projects.

This isn't true. PHP/FI was written in C. Here's Rasmus announcing it to the world in 1995: https://groups.google.com/g/comp.infosystems.www.authoring.c...

One day I tried Python, learned that everything is passed by object reference, and set Perl aside and never looked back. There was so much less mental overhead that Perl never lured me back.

Yes, the left column wraps on mobile.

Perl is a more expressive more fun language, but I do find that the more restrictive nature of Python leads to me writing better, if a bit more verbose code (better as in more readable and maintainable). I would start something in Perl using a few fancy tricks, then come to hate my "clever idea" a few days later when trying to debug it. I do miss it though.

OTOH, a long time ago I used Perl seriously, so I'm familiar with the language.

https://leanpub.com/perl_new_features

  typeof "" == string
  false

I need to hear more about that.

    perl -MJSON::XS=encode_json -MData::Dumper -E 'my $d = { foo => 42 }; say encode_json($d); say "foo is $d->{foo}"; say encode_json($d);'

    {"foo":42}
    foo is 42
    {"foo":"42"}

The only reliable way to serialize a value with a desired type is to request that type explicitly--as one might do to represent a large integer or very precise decimal in JavaScript or JSON, for example.

The fact that they need to literally fortune-tell from Perl guts if something is a number or a string is telling as literally every other mainstream language including current dialects of Pascal has this problem solved. But I'm most unimpressed by the fact that merely looking at a variable will mutate its internal representation enough for there to be externally-visible effects.

It doesn't matter if JSON::XS is looking at the internals wrong, or if it's Perl's behavior at fault: from whichever angle you look at it, the whole thing is a tangled mess of wrongness.

From my reading of the documentation of the former (especially the MAPPING section), it has the same problem for the same reasons.

the whole thing is a tangled mess of wrongness

Perl has monomorphic operators and polymorphic values. Every time someone tries to flip that, whether encoding arbitrary data structures to monomorphic values via a polymorphic visitor pattern, the smart-match experiment, or (as I already mentioned in this story's comments) polymorphic operators for data structure dereferencing, these problems occur.

Regardless of whether anyone believes that Perl's operator/value design is good or useful, that's how the language works. Working at cross purposes is an exercise in frustration. (I'll leave analogies about duck typing, contravariance, casting, and type erasure to people who like debating programming language design.)

      ~ perl -MJSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'                                                                                                   
    {"foo":42}
    {"foo":"42"}
      ~ perl -MJSON::PP -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}
      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}

However, it "works as documented" when the implicit conversion is the other way around:

      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => "42"}; say encode_json($d); $d->{foo} == 0; say encode_json($d);'
    {"foo":"42"}
    {"foo":42}

Nothing in the typelessness of the language, though, makes it necessary to flip any internal state of a variable, though, any time its usage context changes. Especially if the state is readable by public API. Even in a typeless language, the "primary" type of the thing, if it's queryable by anything at all, should intuitively be what it's being set to by assignment or other kind of explicit mutation.

https://perldoc.perl.org/perlnumber

  raku -MJSON::Fast -e 'my $d = {foo => 42}; say to-json($d); say "foo is $d<foo>"; say to-json($d);'

  {"foo": 42}
  foo is 42
  {"foo": 42}

Now, I have touched Perl in decades (oof, that’s rough to type) and that someone might be the official Perl leader for all I know. I don’t think it is, though.

The language is run by a “steering committee”.

The community has a couple of shining stars such as Mohammad Anwar who runs The Weekly Challenge https://theweeklychallenge.org/ and Gabor Szabo https://perlmaven.com/about

They are also both co-editors of the Perl Weekly https://perlweekly.com/

The Perl Foundation co-ordinates activities such as grants funding development, fundraising, and conference organizing. https://www.perlfoundation.org/

There are also a few senior Perl personalities still around such as brian d. foy who continue to write and update books and blogs.

The post-Larry Wall community seems to be doing ok so far. What is notably missing is more active participation from companies making the most use of Perl such as Craigslist or Duck Duck Go.

May your tribe increase.