Why Perl in 2020

[ait]

Dear fellow monks,

This is an opinion piece, flames > /dev/null please.

As this crazy year approaches it’s culmination, I would like to reflect on why I still choose Perl (and C) for most, if not all, of MY work. Disclosure: I make a living with Java, Docker, AWS and a lot of tools considered “mainstream”, but I do this because companies are already biased towards what’s popular, not necessarily what’s best. And they pay good money to continue with their suffering.

In my personal endeavours however, I rarely leave the ecosystem of Perl, C, FreeBSD, and PostgreSQL. It’s a sharp contrast to today’s virtualized and SaaS world, and I wonder how these companies are so stupidly herded into working like this. I mean, back in 2006, I was creating Web Services on mod_perl2 that were hitting 6.5K TPS on a single node and I was deploying with FreeBSD Jails, almost identical to what people are doing today with Terraform and Docker, albeit, at a micro fraction of the cost. Today, the best stuff I see with the container-micro-services-mania, is a few hundred TPS at best, and extremely costly and complex. People are probably spending 100x as much as they would have spent, using bare metal and real people.I mean real programmers and sys admins who actually knew what they were doing to fine tune a real architecture.

Something smells really bad.

Sure, the modern environments shiny, somewhat convenient and hip, with SaaS or GUIs for most everything. But it’s costly and stupid. My guess is that companies will start to wake up one day, like from a bad hangover and say: W.T.F. are we doing? And it’s not just AWS, but to me the whole toolchain is broken and just crazy. The amount of waste is just horrendous and unsustainable. Just how many layers of shit are we going to continue to pile up until we realize something smells really, really bad.

Same thing with programming languages. The Java world is honestly laughable, nobody really knows what Java is anymore (most everything relatively useful and “modern” in Java is based on bending the language with generics!), and “portability” is a widely disproven myth. Then you have the plethora of new and hip languages and frameworks and the young coders who think just because Google or Facebook backed it, It must be good. Guess what, most companies are not Google or FB.

But when Netflix wakes up and rewrites their CDN on bare metal with FreeBSD it hardly makes the news.

So back to Why Perl in 2020...

Well first, we finally got rid of the Rakudo shadow(see Note 1 below) Raku and Perl languages were finally separated, lifting the long cast shadow of "Perl 6" on Perl, and Perl 7 is now on it’s way!

I can’t believe we didn’t see this textbook example on how to kill a good existing product: advertise the new one is coming, before it’s even born. There are so many examples in history, of organizations shooting themselves in the foot this way, it’s even stupid. And yet, we did exactly that. The way Perl 6 was managed was really destructive to our beloved language, and our community. Yet here we are. We survived, we are tired and demoralized, yes. But I truly think we can finally start to heal and oxygenate the ecosystem with the coming of Perl 7.

It’s time for a new dawn of The Programming Republic of Perl. Yes, we have lost a few battles, but this is a long term stamina race, not a short term sprint. There is a new saying amongst investors these days: the age of the Unicorns is over, it is now the age of the Camel. I think we should take this one home.

So why Perl in 2020, or 2050 or 3020? Simple: Perl is probably the most malleable language on the planet. I don’t think people realize it, and truly understand the value of this. IMHO, it’s the one thing that no other language can really come close to Perl.

You can start Perl project as a one-off script and then refactor it all the way up to complete Object Model like Moose (contrary to the half-baked Java OM), or you can go the Functional route, or better yet, use both. You can evolve your code using different paradigms and different frameworks (all staying within the same CPAN ecosystem) to address different problems you will encounter along the way. You can hammer out performance bottlenecks over time, even refactor some portions to C, easily! You start out with a simple script and wind up refactoring portions to different frameworks such as POE, Catalyst, Mojolicious, Dancer, etc.

Mojolicioius itself is based on the same principles (start simple, grow and refactor as you need), which is actually a unique feature of the Perl language itself.

There is a plethora of other great tools and frameworks in the ecosystem, for every taste, and you can use the same language for your complete toolchain including operations and sys admin. I mean, how cool is that?

The widespread rumor that that Perl is a write-once language is such bullshit, that people who spread it must have never actually done anything in Perl and probably in any other language, or in their miserable lives for that matter. This unfounded myth cannot be farther from the truth. I have taken all kinds of legacy Perl and slowly transition it to modernize it, or to change it’s structure completely in incremental and iterative phases along the way. All other lagunages I’ve worked with, would require complete re-writes, but not with Perl. With Perl you can gradually transition and solve specific issues you find along the way.

There is no such thing as unreadable Perl. It’s only unreadable if you are ignorant, and as such any language that is not “ for dummies” will not appeal to you. Go code in Python and be happy, but don’t trash talk Perl just because you don’t get it. Perl is for the artists, the coders that truly want to express themselves in the code itself, to make the code beautiful to them, not to anyone else or some academic fool. Perl can create beautiful code that may look ugly to someone else, that’s perfectly fine. Such is art, and programming is an art, no matter how hard we try to define it in any other way.

I haven’t seen much talk about this malleability of Perl, which to me, is frankly unique. I don’t have the academic background in computer languages to formally describe why this is so, but I do have the experience. That is over 30 years of it; not only with Perl, but with MANY other languages. I know what I’m saying is a matter of fact, but I cannot formally describe it or prove it formally. I believe this is a topic that should be studied and formally described, and it’s something that could surely help put Perl back in the place where it belongs: which like C, it’s probably almost the perfect General purpose language.

Today’s startup world is fast paced and very dynamic. Product requirements evolve in real time with actual product usage and software needs to adapt at lighting speed. When I see companies struggling every day with even the simplest of problems, I cannot believe they are not exploiting these capabilities of Perl.

Happy holidays and may the next year bring you all the best!!

Alex

Notes and Errata

Note 1: The original phrase was offensive to Rakudo which was not the intent. Please refer to commentary below for details and clarification.

Note 2: It is worthwhile to read the comments and replies, especially the the deeper nodes because there is A LOT to learn, A LOT MORE than in my OP. It made me realize there is much more to the Perl 6 story than meets the eye. For example, that early on there was mention to the second-system effect and the Apocalypse, "Second System Syndrome Done Right." , etc. There is also mention on the Three Tales of Second System Syndrome where PHP and Python went through similar processes. So please read the full commentary and deeper nodes for wonderful gems of wisdom, from our much wiser fellow monks.

[VinsWorldcom]

Well written. But some harsh words in there for the new DevOps, microservices nirvana :-) ++ anyway!

Kidding aside, I don't think it's all that bad ... although 20+ years as a network engineer, I've seen a lot of wheels re-invented and lots of the Docker, Kubernetes, microservices ecosystems re-invents a lot - like DNS and overlay networking. I'm all for change if it makes things better, but change for change's sake - I (and I think the collective "we") can do without.

I always lament the biggest advancement in network automation over the past 20 years is moving from screen-scraping Telnet with Perl to screen-scraping SSH with Python. Not that I'm down on Ansible, it provides way more than my little Perl script (better templating, more device support, etc.) but the software abstraction band-aid did not solve the underlying problem - network devices do not have a common language. Maybe the Ansible development effort would have been time better spent in pushing forward NETCONF or similar open standards for network device data model abstraction instead of interface abstraction.

Cheers.

[marto]

On a similar note, see I founded a company called Perl Research Institute, Ltd.: "The main purpose of the Perl Research Institute is to restore Perl's honor.". Google translated from Japanese.

[Leudwinus]

Hi, Alex,

That is a great writeup and really enjoyed reading it. For background, I am not a professional developer and just program as a hobby. As such, I am free to choose whatever language suits my fancy. It's funny because when I first started on this journey, I swore I would never touch Perl as it was the most inscrutable and impenetrable language I encountered. But I recently decided to give it a try and have to say I have been pleasantly surprised. In addition to what initially drew me to it a few weeks ago, I've come to appreciate a few more things about the language, none of which are new to the stalwarts who ply the halls of the Monastery:

• Similar syntax to Bash, awk, grep, sed and other tools you commonly use on the command line. While not exactly identical, I like that they share a common structure which makes it easier to move between them.
• All (of my) problems have already been solved! Because Perl has been around for so long, virtually any problem I can think of has been addressed and written about multiple times, in places such as here, Stack Overflow or in a multitude of books. You can save a lot of time by not reinventing the wheel as chances are, someone has already laid the groundwork for you. And I'm not just talking about the large number of modules available in CPAN either.
• Friendly community. As someone who is not a professional developer, I know I will get stuck on problems. The Perl community here and elsewhere has been beyond generous in helping me get past these issues. For me personally, this factor probably outweighs whateve technical merits a language brings because if I can't get help to leverage a language's strengths, I'm not going to get very far.

The one downside for me is the TIMTOWTDI philosophy of Perl. I know that many advocates espouse this a a good thing but I sometimes wish there was just one idiomatic way to do something. I routinely struggle with the paradox of choice in many aspects of my life and this is one area where I wish I wouldn't suffer the same fate. But otherwise, I am really enjoying Perl. I've even managed to amass 13 stars in this year's Advent of Code competition with what little spare time I have this time of year. And I have to say, I'm really enjoying it!

Gratias tibi ago
Leudwinus

[Discipulus]

Discipulus Leudwini saluta, (latin greeting)

> The one downside for me is the TIMTOWTDI philosophy of Perl.

Freedom is hard. Only the pure slave has one and only one path to follow.

As you are somehow new to Perl this can be confusing, but you stated you liked the similarity to bash, awk, grep, sed and other tools you commonly use on the command line. People coming from C recognize other similarities, functional programmers find they can program with Perl in the way they like, as OO people do. For what I saw from wiser monks Perl permits any programming tecnique without complaining.

This is the malleability ait is speaking about. This is what makes, in my opinion, Perl a humanistic language: the programmer is as free as possible to choose their own way to reach their goals.

I started as you as hobby (but many years ago) and after the first shocking impact with sigils (I wrote just few html tags before: no basic, no batch, no bash) I found very comfortable with Perl exactly because it permitted me to express myself in a primitive way without complaining. Then it is up to you to change the approach, but only if you have the need. I wrote my first real module (not a mess of exported subroutines, a real module) ten years later or so. Only recently (2 years ago) I wrote a real module with a decent test suite worth to be published on CPAN.

So, as you are writing from an abbey near Augusta Trevorum, you can now meditate about aribitrium with this sentences from my homeland: liberum arbitrium est habitus animae liber sui

L*

[tangent]

The one downside for me is the TIMTOWTDI philosophy of Perl. I know that many advocates espouse this a a good thing but I sometimes wish there was just one idiomatic way to do something.

There is a way to force yourself, or your team, to do things in a specific way and that is to use the Perl::Critic module combined with a set of your own policies. You simply pass everything you write through Perl::Critic, during a testing phase for example, and it will list everywhere you have broken the policies. After a while, a habit develops and your code becomes very consistent first time round. Great for new team members to help familiarise them with the house style.

[Discipulus]

Hello ait and thanks for this meditation, I read it twice.

Just my 2cents (and if you dont already know, they are really 2cents: I'm a Perl only programmer, with minimal excursions in other languages and sadly my perl activity is no more bound to my employment).

Making things complex is part of the business. While Perl defines itself as postmodern it is really more humanistic exactly because its malleability. As you know, Perl is extremely portable and supports a wide range of complexity. As you described very well, it just run from scratch and can be used as prototype or can be extended to a full featured program, gradually. This is what fascinate me after so many years: the programmer is in the center not the language nor the business scheme.

> .. using bare metal and real people.I mean real programmers and sys admins who actually knew what they were doing to fine tune a real architecture.

This sounds so wise that clash against what I see everyday around me.

Why cars have not interchangeable engines? For the same reason everything nowadays is virtualized and the real service is beyond many layers of abstraction and complexity, or as you said, layers of shit. Complexity does not sum up: it multiplies, but do you want companies managers understand this? Good luck.

The fragmentation of the work (and of workers too) is a central point in the economy model we are living in. The future is toward specialization and we will be (or our children will be) so specialized at the point we will be unuseful. 2050 or 3020? We will be at the best feeders for machine learning programs.

I suspect the same is valid for programming languages: take a glance to what microsoft is pushing. No one is anymore able to grab the big picture and the tools they use intentionally cover the picture with fog and.. clouds.

Virtualization is handy but was the ram cast into the market to sell incredibly powered hardware and to make it economically affordable you must put everything and more there adding many layers of complexity in one single shot.

Here in Eataly students learn Python at univeristy and I had a little (money driven) excursus with it. Basically is like playing Lego studing Architecture and when it comes to do more serious things I saw them installing a gargantuelian mega framework with many dead ends installation issues and unresolved dependencies (..how much I love Perl errors!) and when you finally get it installed you merely feed data into others work hoping they manage your data correctly.

Who want the programmer freedom (and the expresiveness, quality and geniality) as the center of the discourse? We want this but not companies.

In the meanwhile we can fight our battles as Perl Community in the fields that will be crucial in the near future and I'm with you when you say that will be a stamina run. Few fields I see as critical are, as VinsWorldcom pointed, networking but I'd stress also on maintaining as more as possible the wide platform compatibility (Microsoft is ugly but is a big share of the market and sometimes our community is too choosey..), parallelization (a big thank to MCE), web (and here we are gaining positions), and unexplored lands as phones, games and robots..

> It’s time for a new dawn of The Programming Republic of Perl.

I'm with you! Even if I suspect the ongoing iron heel does not like very much the Republic part.

Good luck to Perl and to our wonderful community for the next year and next eras!

L*

[bliako]

Making things complex is part of the business.

Today this observation is common among almost everybody. I will add "Making useless things" ("useless" in every sense of the word), and "inventing new (consumer) needs" (invent vs discover) and "working more (stressful) hours". But why? We were told that the Free Market and especially that "Invisible Hand" will take care of itself and select the most optimum solutions for our comfort and happiness as human beings. Today it is obvious that this is pre-conditioned on profit aligning with happiness. A claim that it was so lame, in hindsight.

I have already expressed my opinion in other posts about the above and how Perl's TIMTOWTDI is a good thing, in that it allows for the exploration of solution space. I would like to see TIMTOWTDI be integral in any future political and economic system (with safeguards against "TIMTOWTDI to screw you!") as this one will either eat us or we will eat it. The Programming Republic of Perl (the ideology of this statement and also the character of the community) can be a bigger thing than just InfoTech.

bw, bliako

[ait]

Wurd.

[Tux]

I wholeheartedly agree to the basis of your post: the useless unneeded adding of layers over layers over layers, which only shows that those who do so do not understand the simple things at the bottom. And they then claim that it is simpler this way. NOT!

I however do *not* agree with your sentiment on raku! Raku is a beatifull new language that has even more whipuptitude and DWIM than perl ever had. I love both, but they serve different goals.

I think they both fir the perl-way-of-thinking: just braindump your solution into the language of your choice, and it almost always works out-of-the-box. TIMTOWTDI. And that serves me fine. As long as I am not shackled by formats and style, I have proven that I am able to solve most of the problems thrown at me with either perl or raku.

I sympathise with woolfy's feelings in this.

[ait]

You are correct. I clarified my post and apologized to woolfy because the term "shadow" was not meant to trash Raku at all! It was meant more as "whilst Raku remained branded as Perl 6 it cast a long shadow over Perl".

Raku could be the best language on the planet, maybe a better language than Perl will ever be, but that is not the issue here, nor the point of the post.

[pritesh_ugrankar]

Hi,

Fantastic article!!. Wouldn't know about the Raku Language cause I never used it. For my purpose, Perl 5 seems more than capable, and yes, when it comes to decoding UTF 16 output, nothing comes even close to it.

I just hope that Perl regains it's position, especially in the DevOps field. It's just too good a language to be relegated to sidelines or be the favourite punching bag.

Nothing against Python, but the Python lovers I've come across seem not to have a "point to make" when I calmly sit down and try to do a point by point analysis of their favourite pet peeves against Perl.

When they tell me about the "weird regex syntax", I show them how the qr and # or ## can make it not only clearer, but powerful.

When they tell me about "Function Signatures", I gently point it out that the feature was experimental and can be used, but also show them how hashrefs can be used in sub parameters/arguments.....Please note, I am not a language purist, nor a trained software developer, but Perl "Just Works" for me.

When they tell me the "line noise", I show them some scripts which are clearly readable, all thanks to the amazing authors who have shown the clear way of writing scripts.

When they say "List Comprehensions/Dictionary Comprehensions", I calmly point them to sort, map and grep.

Then I ask them if there's something like a "state" variable in Python, or how my script/comments are not bounded by tabs/spaces, or the ternary operator, or qr function, or the simplicity with which I can write a command output to a file (no sub process shenanigans), or my favourite, the UTF 16 handling, or how my and our help me with controlling the scope, or the python equivalent of  use strict and  use warnings or the amazingly powerful references ( I just use 10% of what references have to offer, but I'm a happy man) they do not seem to have a satisfying answer except "It's not really needed/It is too cryptic" or some similar excuse.

As a final point, I show them Strawberry Perl, how it comes pre bundled with so many modules, how easy it is to simply move from one version to the other by just pointing it to a specific perl version, and of course, how the Portable version makes "Admin Access" a non issue, they generally "get my point" and let me be.

[talexb]

For me, in my current position as a maintenance programmer, Perl is necessary in 2020 because it was used in 1995. But more to the point, I can still get my job done very quickly in Perl. I could get the same result in C, but that would negate all of the excellent code that's already available and proven -- that's Perl's secret weapon. Sure, Perl's performance isn't going to equal that of C, but the development time of Perl is tiny compared to C.

The Raku excursion is an interesting side-line -- I've tried bits of this language now and then, but I think I may be stuck using Perl 5 (or Perl 7); that's not a bad place to be right now.

Happy holidays, everyone, and please stay safe!

[fidodido]

I am new here, but I cannot tell you how profoundly knowledgeable I find this article to be. I wish I could allocate all my daily points to this one article.

Which truly makes me wonder, why such a fantastic language, enriched with the amazing modules, paradigms and most importantly, such an amazing, knowledgeable and genuinely helpful community is looked down upon. Perception is stronger than fact I guess.

"Today’s startup world is fast paced and very dynamic. Product requirements evolve in real time with actual product usage and software needs to adapt at lighting speed. When I see companies struggling every day with even the simplest of problems, I cannot believe they are not exploiting these capabilities of Perl."

This reminds me of a comment on a youtube video where the author of the said video was stating how Perl is not used much now a days. The comment was from a (what I think )prolific perl user( I think his name was daveorg or something like that), stated how Perl is still used to do huge number crunching and moving data in and out of databases at lightening speeds.

P.S.: Not sure about Perl 6 (Raku), because, I am not that smart to know the difference or appreciate the advanced features it might have over Perl 5 or any other language for that matter, nor have I ever tried it.

[jo37]

ait, you just wrote my "node of the year". How can you read my mind?

[woolfy]

"Well first, we finally got rid of the Rakudo shadow, and Perl 7 is on it’s way. I can’t believe we didn’t see this textbook example on how to kill a good existing product: advertise the new one is coming, before it’s even born. There are so many examples in history, of organizations shooting themselves in the foot this way, it’s even stupid. And yet, we did exactly that. The way Perl 6 was managed was really destructive to our beloved language, and our community. Yet here we are. We survived, we are tired and demoralized, yes. But I truly think we can finally start to heal and oxygenate the ecosystem with the coming of Perl 7."

It is difficult for me to express how angry, disappointed, sad, mad, and enraged I am because of this paragraph. And all those people who reacted to the whole post as a supreme bit of wisdom. I guess nobody needs to wonder any more why I (and other) left the Perl community. Please be free from the shackles we from that damned language put on your ankles. Free at last, heh? Good luck with your next disaster, Perl 7.

Yes, I am angry. And I know some of you are happy to see me go. For good. Rid of my shadow.

[Discipulus]

Dear woolfy,

Even if I was never deeply involved in the Perl world I know you as a fundamental column of the community.

I never commented about perl5/6/7/camelia/raku/whatsoever because I have no knoweledge nor skills to apport something useful to the discussion. Nor I never had the time to investigate nothing but (classic) perl.

I hear my name in your:

> all those people who reacted to the whole post as a supreme bit of wisdom.

I still think the original post is a bit of wisdom and I intentionally avoided the perl5/6/7/raku/whatsoever part in my comment.

But dont you know, being around for many years, that many people think this way? In many degrees, variations and shades? Perl6 did not changed the name to Raku?

A community must be sensible and sensitive about people perceptions in all its shades and taking a common denominator to progress as community.

If you get angry for the opinion you quoted, it means the wound is still open and I'm sorry for this.

I hope the best future for all projects perl5/6/7/raku/whatsoever and I'd not cast a disaster word to no one of these pieces.

As you can imagine I'm not happy at all (and I'm sure most of us) to see you go away, nor to see you angry. Democracy, or well freedom of expression, often offers mouthful hard to swallow but get angry does not help.

L*

[woolfy]

Thank you for kind words. They lessen my anger, but increase my sadness. Because they made me think back to the time when I decided I had to leave the Perl-community, and later the Raku-community too. Sadness also because I do not see enough reasons to come back on that decision. I do not see the need for anybody on this forum to write so negatively about Raku.

[ait]

I truly apologize if this generated any bad sentiment. Maybe I could have used a better choice of words, but I was trying to preach a reconciliatory message here, so pls. don’t kill the messenger. The result of Perl 6 is what it is, regardless of the effort and intention. I surely am not blaming Perl 6 per se, or targeting any particular group, and much less any individuals. When I say “ management” I am referring to the marketing aspects, not the execution and/or the product as such. My point is that it should have never been advertised as Perl 6. And this started with Larry Wall himself...

You don’t start a new version of a product by advertising: well you know what, Perl 5 is hopelessly broken and I’m going to set out to do it right this time. Lots of people were quite happy with the sigils and obscure magic variables and all the other quirks of Perl 5, and felt betrayed. There was no need to start off a project by trashing your old design and alienate a big portion of your loyal followers who actually love these “features” that you are NOW calling design flaws. People may not want to admit it in public, Mr. Wall, but I personally found that very distasteful and hypocritical when you’ve been preaching almost the opposite in the past few decades (linguistic origins, write what you mean, TIMTOWTDI, etc.) So NOW we want to clean up the language and make it more “appealing” and “correct”. How do you think that made the community feel as whole? When the founder himself is almost saying: well Perl 5 was fun but it was a mistake. Let’s create a language for the “future generations”, wtf? What happened to THIS generation, where do I, the CURRENT Perl hacker fit into all this? That OBVIOUSLY alienated a lot of people from BOTH Perl 5 AND Perl 6.

And if that wasn’t enough damage, we top it off by calling it Perl 6, and then take over a decade to deliver it. Making the whole language and both communities (now weakened and divided) become the laughing stock of the Internet. Like you, a lot of people simply left, and we let Python take over the world, even in bioinformatics! THAT is shameful. Everybody is angry and sad. It’s not just you. It’s all of us. We ALL screwed up, and we ALL lost, my friend.

The post was not about trying to show off a supreme bit of wisdom. It was to finally say that it’s time to heal and it’s time for both projects to succeed in their own right. Perl 6 was never a successor of Perl 5, and that is clear to everyone now. THAT is what I meant by “shadow” and I’m sorry you took it the wrong way,

It was a mistake that it started the way it did, but I am sure that no one had bad intent, especially not Mr. Wall, and surely none of us in the mere mortal user community. But the fact of the matter is, that a starting a NEW language and calling it Perl 6, hurt everyone. And I think it’s time we allow for these two projects to heal, make peace, and move forward in their own right, and hopefully together.

[woolfy]

Apology accepted.

In my recollection, Perl 6 did not start with marketing. It started out of frustration because of several problems that were needed to be solved to move forward with Perl 5, and solving those problems would mean breaking backward compatibility. It started with a cup-throwing moment. With groups of people sitting around and discussing and writing down things that needed to change. It took quite some time before marketing came into it.

Looking back to those years, I still think that when more people would have joined in, helping development of Perl 6, a functioning programming language could have come into existence before Pugs was made by Audrey Tang. If more people would have joined in to for instance convert a lot of modules from Perl 5 to Perl 6, to make a grammar in Perl 6 to execute Perl 5 code, both Perl 5 and Perl 6 would have benefited greatly. Instead, many people felt betrayed, and I remember mostly from those years a lot of flame-wars and a lot of people leaving and not returning.

Marketing... I still have stickers and buttons that say "we suck at marketing". We really do. Looking back at my own efforts in marketing Perl (5|6), I wonder how that money, time and energy could have been used better. Marketing for Perl has never been an impressive thing. I doubt more marketing would have improved a lot: we needed educational materials so Perl could be taught at schools and universities, talks about Perl at big conferences, articles about Perl in important magazines, etc, and I have been at brainstorm sessions to make overviews of what needed to be done, and we just did not have enough volunteers to do these things, or money to hire people to get them done.

Most of those problems from the beginning still exist in Perl 5, and breaking backward compatibility still causes anger, as was shown with the changes in smart match by Zefram.

I still love Perl. Both Perl 5 and Raku.

[Anonymous Monk]

Good luck with your next disaster, Perl 7.

Thanks for this outburst. P6 was demonstrably bad for Perl, given that it isn't Perl. You say you left, yet here you are, spreading the bad vibes, really sounds like you moved on to more positive hangouts

[Leitz]

Virtualization is very useful for application isolation. Bare metal doesn't work for most applications; the cost in hardware overhead is high and the utilization is often sub 10%. Yet the application must be isolated from other applications for security or configuration reasons. Some things run better on bare metal, but the datacenter cost can be very high for medium to large companies.

Perl is very much a write-only language for most programmers, and even many Perl programmers. If the average coder has to mentally parse several sigils, matrix that with context, and then look deep into a subroutine to see what is done with a variable, it's not a good thing for the programmer. It can be done, and I'm sure those who live and breathe deep Perl on a daily basis can mentally parse things much faster. Most of us can't do that. We can parse things in our spoken language because we have lived in it for years. Yet we still miscommunicate and misunderstand. We spend hours trying to find some way to write a test for some undocumented subroutine that's a hundred lines long and heavily interdependent with other subroutines that make no more sense than this one.

Your post makes me think you're a skilled Perl programmer. Perl is a great language that can solve a lot of issues. The more we understand why "they" are making choices we feel could be done better, the more we can help them see why Perl might be a good fit for them. You have the ability to solve a lot of problems with Perl, probably moreso than many of us.

[shmem]

Perl is very much a write-only language for most programmers, and even many Perl programmers.

This argument always struck me as being plain silly. That's like saying that I write some text in German, and am later unable to read it because it is not English. Or that writing something now means misunderstanding myself in the future. Sure, every outside is a more or less gross misunderstanding of an inside, not only when it comes to e.g. giving account of one self, but that's not the point here.

If I talk with my Syrian or Turkish fellows, hearing their particular use of the german language, I can understand them and adapt to their peculiar, sometimes funny, constructs; and by talking likewise and applying sparse corrections I can gently lead them to a better understanding of the language.

Talking with speakers of the various german dialects, I can understand them (if not, I ask), but I wouldn't be able to express myself the same way without picking up not only their accent, but a plethora of other idiosyncrasities as well. And yet that's all german.

If the average coder has to mentally parse several sigils, matrix that with context, and then look deep into a subroutine to see what is done with a variable, it's not a good thing for the programmer. It can be done, and I'm sure those who live and breathe deep Perl on a daily basis can mentally parse things much faster. Most of us can't do that. We can parse things in our spoken language because we have lived in it for years. Yet we still miscommunicate and misunderstand. We spend hours trying to find some way to write a test for some undocumented subroutine that's a hundred lines long and heavily interdependent with other subroutines that make no more sense than this one.

Same goes for other languages without sigils: look deep into a subroutine to see what is done with it. But if I see a bare identifier in, say, C or python, I have to look up declaration and typedef: is it a char *, a dictionary, a function pointer, a struct? Sigils tell me clearly what type of variable this thingy is, and if it is a reference, the deref, its usage, tells me what's inside.

Complex things are complex, in any poorly written program in any language you can find yourself struggling with an undocumented subroutine that's a hundred lines long and heavily interdependent - that's not a perl feature. Yet perl is immensely more parseable than other languages whithout sigils - because of the sigils!

There are people which can read a page of C code at a glance and understand what happens - I can't for lack of training, but surely can do with perl code.

[betmatt]

From your position I think that your sentiment is correct. A nicely written article. Artisan programmers will surely however only ever make a proportion of the programming work.

I have spent quite a lot of time looking at Python. When I look at Python code I miss Perl's syntax. However I do appreciate the requirements to conformity. The usual problem with programming to 'your own style' is that a lot of the time it is extremely dificult for others to understand 'the code'. That is great if we want to explore the world of possibilities. It does however make Perl a hard sell. This is not just because of academia. It really comes down to the requirements of industry.

When it comes to Raku. I've seen a talk at a Perl conference on this language. Having studied Python I can safely say that Raku looks like a beautiful language. I do believe that Raku and Perl 7 will at some point combine. The reasons. Well. Cloud based computing will necessitate object orientation of Python fame. Raku will offer that. Multicore processors will demand functional programming of the quality of Haskell. Raku will offer that.

I do think that if Perl 5 or 7 works well for you, then carry on using it. Unless you want to do something like AI then keep going with Perl. The reason: People overuse Object Orientation (OO) in my opinion. In such case, your point on migrating from Procedural to OO then becomes valid. Remember this. For Python, if you know and understand OO, then OO is fine. People get tied up in knots with OO because they don't fully understand the theory.

One of the reasons I originally went with Perl was because I didn't think that Java had the right syntax for OO. Python has gone a long way towards fixing that in my view. I think that Raku will learn from Python.

Given all of that I predict that Perl will comeback at some point and take Python's crown.

[stevieb]

"I do believe that Raku and Perl 7 will at some point combine."

No. Way. In. Hell. We've got 20 years of nonsense trying to separate the two. There is no way they will ever converge.

"People overuse Object Orientation (OO) in my opinion."

Would you mind sharing what your opinion actually is? I've got 54 (I think) CPAN distributions, and I'll bet less than 10% are non-OO. Most software in other languages I write in are OO as well. Typically, if I'm not writing low-level hardware interface software in C, I like OO (for the most part). What in your mind defines when OO is being overused?

"For Python, if you know and understand OO, then OO is fine."

Python, in-and-of itself, inherently is OO, right to its core. Whether you know and understand OO is irrelevant, because if you're using Python, you are by default using OO even if you don't want to ;)

[eyepopslikeamosquito]

Python, in-and-of itself, inherently is OO, right to its core

Really? Care to elaborate? Note that Matz invented Ruby because he disapproved of Python's OO, as indicated here:

I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language – OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it.

Matsumoto describes the design of Ruby as being like a simple Lisp language at its core, with an object system like that of Smalltalk, blocks inspired by higher-order functions, and practical utility like that of Perl.

See also: old stack overflow discussion of Python OO