[stakhanov]

> Python programmers would [...] bad mouth Perl all over the internet [...]

I am one of those, and I disagree with the moral connotation of that framing.

When you're in the know and give advice to someone who isn't, or when you're the previous generation passing on your lessons learned to the next, then you have two paths. You can either be honest about things that don't/didn't work, so mistakes won't be repeated. Or you can make it seem as if pixie dust covers everything you have expertise in that others don't and everything that your generation did that the next one will never know, so you look good. -- I don't think that the former path is the more morally reprehensible one at all. "Bad mouthing" is the wrong analogy here.

[daneel_w]

> You can either be honest about things that don't/didn't work, so mistakes won't be repeated.

What things don't work, then? There's a difference between disliking something to the point of personally being incapable of working with it, and something that in itself truly does not work. My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.

[kamaal]

>>My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.

People who haven't used Perl to its full power have little how idea just how magical a language it was/is.

Have seen people's jaws on the floor watch Perl guys do automation they always thought was impossible, even more so delivered in such record times. CPAN itself as an idea was way ahead of its time.

Around COVID I had a project delivered, in a week. I basically wrote a Perl script that wrote Apache Pig scripts(Basically using Perl like a macro facility, and Perl is great at anything text). It was a massive project which otherwise would have taken more than a year to deliver. When I did show the team what I had done, had them in total awe in the same way people look at Claude Code today. Nevertheless it was the same reaction, when the project got done, they were not comfortable that some programmers could do stuff like this, which seemed alien to the remaining.

I have a belief that proliferation of Java/Python stunted the growth of web dev, and a lot other industries. In some way the last decade was entirely slowed down by adoption of these technologies. If Ruby/Perl were there things would have been way better.

I do love what LLMs are doing to Java and Python today.

Software development was never supposed to be as slow as what Python and Java made it.

[stakhanov]

> People who haven't used Perl to its full power have little how idea just how magical a language it was/is.

...why would you prefer to reach for the "no true scotsman ...", rather than read in any one of two other places in this thread that you are dealing with fellow scotsmen here?

I can't debate Raku with you, because I don't know any Raku, because, why should I? Life is short. I do know Perl 5, and the only context where a discussion of Raku even makes sense is as an upgrade path for Perl 5. Upgrade path doesn't mean that a program written in Perl 5 should run with unaltered syntax and semantics in Raku and not panic. Providing an upgrade path for Python 2 was one of the primary purposes of Python 3, and they didn't understand it that way either. Upgrade path simply means: Leverage syntax and semantics and mental models already in programmers' minds and change them where necessary to trade off short term pain for long term gain. (But it's less pain than learning a different language altogether with completely different syntax and semantics and mental models).

I can give you a list of grievances I have with Perl 5. Maybe Raku addresses some of those. Maybe it doesn't. I don't know, but also, it doesn't matter. The late arrival of Raku means decades' worth of people using Python and other languages as an upgrade path for Perl 5 instead, so Raku addressing any of those grievances is now closing the barn doors after the horse has bolted. Any Perl 5 codebases still out there are run by people who are so allergic to the idea of having to touch their code, that Raku isn't an option for those folks either.

Having said all of that: Some of my grievances with Perl 5:

* No separate types of bytestrings versus sequences of unicode codepoints. Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake. This includes databases backing Perl applications, where they themselves don't have enforcement, so even if you threw away all of your code and started from scratch and just wanted to keep your data, Perl 5 would still haunt you from its grave. -- Having strings not be mojibake is easy as hell in 2026. Perl 5 makes this easy thing impossible, so I really don't share your idea of "make easy things easy"

* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.

* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.

* Perl one-liners, and RSA decryption written in the form of a camel, make for nice t-shirts, but the same argument as above applies to them. There is no purpose today (but probably never was) in one-linerism because an LLM will knock out 10 lines of Python just as fast as 1 line of Perl, and reading those 10 lines of Python (which is the part that actually still matters) is more ergonomic than reading the Perl one-liner.

* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.

[lizmat]

* No separate types of bytestrings versus sequences of unicode codepoints.

Fixed in Raku. You either have a string (Str) or a bytestream (Blob).

* Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake.

No mojibake in Raku.

* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.

Raku has single object / type system.

* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.

Raku regexes allow arbitrary whitespace, can contain comments and are composable.

Grammars are collections of tokens / rules / regexes that can be used to build an AST, and actions that can take that AST and build another data structure of it. A grammar is used to parse Raku itself.

Grammars can be subclassed or have rules / regexes mixed in (slangs).

* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.

The Raku ecosystem, albeit much smaller, is growing and actively maintained: https://raku.land