What's the best way to get thicker skin about Perl's unpopularity?

I also have a curious experience in the workplace I'd like to share. Around the time I wrote Unix shell versus Perl (2008), I successfully argued:

Notice that the above is arguing against Unix shell scripts, not specifically for Perl. Indeed, the same essential arguments apply equally to Python and Ruby as they do to Perl. However, I view Perl, Python and Ruby as essentially equivalent and, given our existing significant investment in Perl, don't see a strong business case for switching languages.

A few years later, I could feel the tide turning against Perl, especially from new hires. One fellow in particular was especially vocal about how much he loved Python and hated Perl. Going with the flow - admittedly partly because I'd learned Python by then and quite liked it - I kept him (and others) at bay by adjusting our coding standards to allow Python in addition to Perl. (To avoid total anarchy, Ruby and PHP were not permitted).

Curiously, after praising Python so loudly for so long, our Python lover never managed to write a single production Python script at work! Why? It turns out, though he "loved" Python, this seemed to be a "theoretical" love, for he was sorely lacking in real Python experience and skills. At least, I was shocked during code reviews because, after using Python in just a few golf games, I was pointing out embarrassing blunders in his Python code. No doubt my many years of Perl experience helped. You see, we were both hired primarily as C++ (not Perl/Python) developers, at least we wrote only C++ at our job interviews. Curiously, he seemed to lose interest in Python shortly after those early code reviews and stuck to C++ after that.

Update: it turns out he hated Perl based on appearances and hearsay because he'd never actually written a Perl program! (Stroustrup noticed similar bigotry towards C++ "twice as many people claimed to hate C++ as had ever written even a single small C++ program").

Since then, it's been impossible to halt the clamour for new programming languages at work, with modern UI tools often requiring Javascript (and derivatives) and modern DevOps tools often requiring JVM languages, such as Groovy, and Banal Configuration Languages (update: see also). As if that were not enough, the younger guys are also screaming for trendy new statically typed languages, such as Golang and Rust, seemingly unconcerned about the impracticalities of rewriting millions of lines of working C++ code or having to maintain organisational skill levels in so many different programming languages.

a "theoretical" love

Platonic? Seinfeld on Platonic Relationships (<< youtube warning)

(In the hope of lightening things up a bit.)

On the same light mood, I got a bit disappointed seing that you put Unix shell script in the same league as Windows BAT. Brrr, BAT is like Prometheus came and asked for Fire back or ... licensing rights. Bloody food? yikes!

But seriously, isn't profit (and cost-effectiveness) the only factor governing a free-market company? A choice of programming language based purely on style will kill that company off. I guess I hold a theoretical and idealised picture of this process because inefficient companies survive for years.

bw, bliako

I got a bit disappointed seeing that you put Unix shell script in the same league as Windows BAT

Agreed. (Sorry about that, chief :). I hope I can ease your disappointment by singling out Windows BAT as the worst programming language I've ever used. Perhaps only INTERCAL (and its infamous COME FROM statement) can compete with it. Thinking a bit more, Cobol and PHP are also right up there among languages I really hated in the bad old days.

But seriously, isn't profit (and cost-effectiveness) the only factor governing a free-market company? A choice of programming language based purely on style will kill that company off.

How commercial companies decide which programming language/s to use is something of a dark art. See also:
• My opinion on this from ten years ago
• a stackexchange question on this topic
• Why Create Coding Standards and Perform Code Reviews? (notes that successful software development is a long term activity and, if you plan to be successful, you must therefore plan for your code base to be maintained by a succession of many different programmers over a period of many years; not planning for that is planning to fail).
In its early years, even a company as big as Google permitted just three languages for serious development work, namely C++, Java and Python. I remember an interview with Guido (can't find it now) where he was asked how come Google came to use Python in the first place and he said he didn't know! (and he was a Google employee at the time!).

I'd like to say one laughter will bury you but we all know this is not the case, sadly.

> What's the best way to get thicker skin about Perl's unpopularity?

They are fashion victims; without harassing them all, you can show a complaisant superiority, as an old and wise man does looking to youngsters. Ask for real arguments against perl, highlighting that you are all professionists and is really unwise to follow a mundane mood against a technology without real arguments.

Then take your time to demonstrate how much false are these arguments against perl.

Never get upset: always a smile of complaisant understanding.

You are in the frontline of the battlefield where perl can raise or decay.

We are all with you!

L*

Perhaps you want to investigate the comparison of security/bugs situation for Perl and Python (comments anyone?). From a quick look I found this: https://www.cvedetails.com/product/18230/Python-Python.html?vendor_id=10210 vs this https://www.cvedetails.com/product/13879/Perl-Perl.html?vendor_id=1885

I would rather sail the Atlantic with a Perl-person rather than a Pythonista. Better problem-solving skills sharpened by years of being exposed to TIMTOWTDI. The concept of TIMTOWTDI also promotes tolerance to other opinions IMO.

Whenever I hear Python, I am reminded of the great Primo Levi and his short story in the Periodic Table, about sourcing Nitrogen for making lipstick. At first he went to his chicken coup but couldn't get enough, then he read that Python's poopoo contain the biggest quantity of N (urea) in the animal kingdom (citing from memory now) and thankfully a circus (zoo?) was visiting the town. So, off he goes to the snake-keeper of the circus and asks to relieve the circus from cleaning the Python's mess. The snake-keeper shows him a long list of people waiting for python poo but the cherry in the pieeopoo is that ... pythons poo just twice a year.

Enjoy the day with an one-liner.

bw, bliako

I'm sorry to "hear" that, rje.

First and foremost, I'd like to thank you for sharing this. It reminds me there are other people facing this same kind of issue. That means we can help each other finding strengh and insight to get through it.

Python has become very popular in the company I'm working for, but even Python is mocked sometimes by Java people, as some seem to have a strong belief that Java is the solution for everything (and here I was, thinking this was a problem of ten years ago).

The mere fact that somebody can believe there's a one-size-fits-all solution suggests a serious cultural problem, in the first place. Needless to say, people who think like that would have a hard time with Perl TIMTOWTDI thing.

But what's ironic here is that my interest in Perl arose because a co-worker in this same company once asked me something about Perl. I had never programmed in Perl until then, so I couldn't help him. Perhaps even more ironic is the fact that he was working on a container.

But anyway, I thought to myself: "if he believes for some reason that I'd have the answer, then maybe it's because I should". I mean, "maybe it's because I'd like Perl". And I was correct. It didn't take me long to see how much enjoyable Perl is.

I've tried to argue with my boss last year about that. I told him how daunting it is for me to have sometimes to get my feet on Java code (not that it happens very often, thankfully), while Perl is never ever mentioned for anything.

His answer was not really surprising:

"I understand you, but I must be able to hire people who can work on it afterwards. What happens if you leave the company? I won't have a good time finding other Perl programmers."

Actually, I think he'd be surprised about how wrong is that last statement, but the thing is I couldn't prove him wrong. I believe groups like Perl Mongers could greatly help on that. However, the pandemic situation brought some difficulties on it.

What always helped me get through such situation are communities, no matter how small they are. They're like a safe harbour. When you know there's people who care about something, that's what give you strenght to fight for it too.

It's just like how many species afford to survive: they work together. Without that, there's no surviving. Bees and ants, for instance. They build their places together so they can survive as a group. I think we can always learn from them.

Comment on your comment. Over here, it's actually the React and Python fans who roil against Java. And yes, y'all are correct -- all this posturing over "I love language X, I hate language Y" is a shallow partisan love, rather than an appreciation of software design.

• A Evolutionary struggle
• B Psychology.

A) open source lives from contribution and bad mouthing the competition helps lifting the own chances.

B) most people want to be on the winners side. The more insecure they are about their own skills the more inclined to mob others°. They might say they are Pythonistas, but an average Perl programmer will beat most of them in Python.

Trouble is the self fulfilling prophecy happening here.

I don't have a recipe for you.

Personally I'd come with a use Perl or die; t-shirt to work and demostrate Perl fun each day. :)

°) "True I beat my wife but hey my neighbor is even worse and always screams at his kids ..."

Personally I'd come with a use Perl or die; t-shirt to work and demostrate Perl fun each day. :)

I'd use one of my perl poems for that shirt with

# *perl*
goto HELL;
[download]

on the back and the poem on the front, adding a snarky footnote:

HELL: {
    eval "die;";
    goto HELL;
    redo;
} # You¹ can't redo.

# ¹) python
[download]

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

I got mine at YAPC Kiew in 2013°

funny enough the "T-shirt constructor" is still online.

https://act.yapc.eu/ye2013/t-shirt/index.html

Maybe you wanna use this model for your own online t-shirt business? :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

°) stayed later at a friends place in Odessa, who turned out to be championing Python. Alone his facial expression after meeting me at breakfast with this t-shirt was worth the trip! :)

Some prejudices on Perl often heard over decades:

• Perl isn’t a real programming language
• Perl is just a scripting language
• Perl is an interpreted language
• Perl is slow
• Perl is too old
• Perl doesn’t really support OO
• Perl programming is considered harmful

And many more. After a while I gave it up arguing on this crap and thought by myself «Kiss my ass!» and did my job as usual. With Perl.

«...contempt...»

This was an issue in any company I was with until I retired. What this Wisenheimers forget or don’t know (!) is that most of their systems rely less or more on Perl: Cron jobs, Backup, Databases, Monitoring, Ticketing, Mail, Firewalls etc. See also

..., Databases, ...

PostgreSQL, which is mainly a C project, has in recent years (!) adopted tap + perl for testing, and total perl files (*.p[lm]) have grown to several percent of the total lines of code in the tree.

And there is PL/Perl

Update: Linked to current version of PL/Perl

«The Crux of the Biscuit is the Apostrophe»

Thank you, fellow monks. I appreciate your thoughtful and honest responses, and ... well frankly, the community is a source of strength with this issue.

Thank you again!

• strict and warnings
• variable scope
• variable assignment in expressions (though there is now a restricted version in Python)
• autovivification
• one-liner capabilities
• sigils

And I don't care for the GIL, but it seems that's a big problem however you slice it, for many languages.

> variable scope

Python has function scope, I think you mean block scope.

I'd add

• Lambdas (= Ano. Subs) with more than one expression

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Python has function scope, I think you mean block scope.

I literally meant the scope of variables. :D

-QM
--
Quantum Mechanics: The dreams stuff is made of

Agreed! Especially Perl vs Python variable scope. This was discussed at length a few months ago -- see especially the many insightful replies from the LanX. :)

I like Perl syntax. Coding/using in perl is enjoyable experience, whereas on other languages there are many places which are not as good as in Perl.

~10 years ago Perl ecosystem was huge - you could find almost everything on CPAN - it was clear for me that Perl solution is always the best (well, almost :) )

However - now I pretty much understand and even support a point of perl refusals.
There are too much missing things in Perl right now:

• CPAN no longer covers all modern techniques:
  • WebASM - there was some discussion on p5p about a year ago but this went nowhere.
  • "neural network" and other data science - there are some old modules but ecosystem is almost empty, at least compared to other languages
  • etc.etc.etc...
• Core language:
  • simple file reads which are present in Python/NodeJS but "cumbersome" in Perl.
    I want functionality of IO::All but available everywhere even without CPAN access. IO::All is too heavy
  • Sets and simple things like 'x' in ('a' .. 'z'); I can write exists {map{$_=>1}'a' .. 'z'}->{x} but this is too much. Core language does not have this as simple as I want it

starting from about ~10 years ago things have globally changed.

Now some personal recent experience.

Recently I tried to use JQuery/Datatables and even found several CPAN modules for it, tried to use these and failed.
After I've failed in perl, I succeeded with NodeJS on that, I got what I needed. I had confirmation on my table that other language's ecosystem is more current.

Perl is no longer of that 20 years ago.
Sorry, guys.

I am still missing 'use strict' in Python, and 'use strict' of NodeJS is not as complete as Perl's one. And also missing brevity of regexps,

....but also I understood that brevity of regexps is compensated by additional code which is needed for instant file reads and other missing core features.

"Recently I tried to use JQuery/Datatables and even found several CPAN modules for it, tried to use these and failed. After I've failed in perl, I succeeded with NodeJS on that, I got what I needed. I had confirmation on my table that other language's ecosystem is more current."

All you have to do is send a JSON response for Datatables to read, you don't need 'Datatables' module to do that. JSON::PP is core. For what it's worth putting together a Datatables heavy application took almost no effort using Mojolicious::Lite for handling everything.

Update: Added JSON::PP is core.

...but this means I need to do all my heavy-lifting myself, whereas I want be standing on shoulders of giants.

ok, you probably know this http://datatables.net/ better and probably already solved similar tasks
probably it's my fault for not finding a good way in Perl - but for me - 20+-year perler - it wasn't easy to do in Perl but easy to do in NodeJS - that infrastructure is currently better supported

> Recently I tried to use JQuery/Datatables and even found several CPAN modules for it, tried to use these and failed. After I've failed in perl, I succeeded with NodeJS on that, I got what I needed. I had confirmation on my table that other language's ecosystem is more current.

Whose magic wand's going to fix that? If you find a library is missing, you are the best candidate to fill the gap!

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

So I found that the library was missing (not exactly missing - there were CPAN modules which haven't fulfilled my needs)
but I found what I needed in nodejs ecosystem http://www.npmjs.com/

But I see your point about creating such a module myself and uploading it to CPAN. And ~10 years ago it was the approach which I probably have choose, because all other libraries are here on CPAN.

Perl have lost critical mass of its users, who will fill the gaps on missing modules, unfortunately for me and for other perl users.

FWIW http://blogs.perl.org/users/sergey_kolychev/2017/02/machine-learning-in-perl.html and my tiny introduction Dataflow programming on CPU and GPU using AI::MXNet

For genetic algorithms here: Re^3: Curious about Perl's strengths in 2018 Re: check possible combination of sum using given array Re: optimization problem

bw, bliako

I saw this blog of 2017,
Reading such articles exactly give an impression that now CPAN have many missing areas of modern techniques
Fortunately Sergey published CPAN module for the missing piece that he found.

My sincere gratitude goes to him, and also to you, who provide efforts to improve this situation.

I've been using DataTables for years and have never found a use-case where a module would have helped. You prepare your data and send it to the front end as JSON. All the heavy lifting in that application is in writing the JS and particularly the CSS. You make a good point but this is a bad example.



The way forward always starts with a minimal test.

...ok,
so probably I should have posted my question here and you could have helped me back then. That's good. :)
Perlmonks is a very strong point of Perl community.

Still, I do not think of my example as "bad example".

see: I tried different CPAN modules, but these haven't fulfilled me.
I honestly searched both Perl @ cpan+perlmonks+google and searched nodejs @ npmjs+stackoverflow+google and found better solution in nodejs land.

I am a bad searcher? probably. should I improve my google-fu? probably.
However I still think this is not a bad example in a sense that this is a real-life example.

I am some poor user who found some solution outside of perl for some reasons....
I do not think that I am alone with such experience

I think that the proper thing to have done would have been to write a new CPAN module that's "exactly what you needed," then share it. Nevertheless, it's impossible for every language to be everything to everybody. That's why we invented – and, very regularly use – more than one programming tool. Why try to "re-create gprolog in perl when you've already got gprolog? Why dumpster-dive into "WebASM" if your only motivation for doing so is to say that you have done it? There's utterly no point.

rust recently appeared as a brand-new language because a group of engineers realized that they were facing a brand-new use case that other languages didn't yet cover. So it goes. Perl is a venerable tool in a society of tool-builders.

we invented

lol. "we"

recently appeared as a brand-new language ... brand-new use case

Clueless, as usual, mike.

Anyone who knows a couple of programming languages already can easily pick up perl in a matter of weeks like I did. So, why are employers afraid of perl? They aren't afraid because someone can't learn to write perl; they're afraid because the next guy will have to be able to read perl. And reading requires a lot more studying and a lot greater knowledge. That's something you can't just learn in two weeks. You have to know all the various frameworks or libraries and intricacies of a language. That requires years of experience. That's why employers are afraid. BUT I think, if you write extensive comments in your perl programs, even a dummy will be able to understand what this program is for and why it does what it does. If you put that much effort into commenting, I think he will change his mind. Write an example program, and show it to him. Show him that even someone who knows nothing about perl can read it and understand it, because that's how you write perl code. He'll change his mind!

Whenever I have an opportunity to mentor people in writing code, I tell them about this habit I've had ever since I became a reasonably good Perl programmer:

Every time you open a new, empty file that will contain source code, the first thing you should write into that file is commentary: a description of what this chunk of source code is supposed to do; its inputs and outputs; a synopsis of its usage and (where appropriate) an explanation of its default and optional behaviors. (Doing this as POD is the Best Thing Ever.)

Don't start writing the actual code until that part is done. (If, as the code gets written, you change your mind about anything, update the description accordingly.)

I've found myself repeatedly relying on this habit when it comes to being able to quickly grok code that I wrote years ago, or months ago, or just last week. It's also very helpful in keeping things clear in my head as I work on the code I'm writing this week.