One of the perl guys (maybe Larry Wall?) said the same thing at a talk once about companies using perl but not wanting anyone to know it because it was a such a time saver they considered it a competitive advantage.
That's still the same about Perl, but for different reasons now.
> While the rest of the world sees Perl as a legacy language and analysts insist that no one is talking about it, our Perl business is vibrant, alive, and growing. Leading companies such as Amazon, Boeing, and Cisco continue to demand Perl skills in their developers while Booking.com is investing in Perl as its core development language. How can this be explained?
> This is the Perl Paradox. No one is interested in talking about one of the most influential modern programming languages yet it continues to thrive under the radar.
> continue to demand Perl skills in their developers while Booking.com is investing in Perl as its core development language. How can this be explained?
It's simple: because rewriting it doesn't make business sense. But from having talked to Booking.com devs, I don't get the impression it's something they'd recommend for new projects.
So while some businesses build on Perl might be "growing", is this because of Perl, despite Perl, or doesn't matter? The success of a business says nothing about the ecosystem surrounding the language they are using (unless they get so big they can shape it). A far better proxy for language health is how easy it is to hire a team of competent <language> programmers at all skill levels - by which I mean veterans with enough varied experience, and college graduates who'll consider programming in <language> without a bigger paycheck. (The ultimate metric would factor in turn over due to dissatisfaction/burn out from tech debt.)
For what it's worth, I still love `perl` for one-liners, because it's far more consistent than the various GNU and BSD versions of `sed`/`awk`/`grep`. But I'd rather be programming something else, and I'd rather be deploying something else, given that consistent deployments are possible now with language-agnostic tools like docker. So a big advantage Perl had is gone.
Yeah, I felt like there must have been a culture shift at Booking recently, because I spent the whole time at TPC::EU Glasgow last year without hearing a single pitch for hiring from Booking. Given that "Booking is hiring" been something of a running gag, something must be up.
It's not all that hard to hire competent and experienced Perl devs if you're willing to hire over the age of thirty, and remote (i.e. not moving to Amsterdam).
I would mostly recommend Perl 6 over Perl 5 for new projects, though. At least for those intended to last more than 5 years (which de facto means 20 years). I know the module ecosystem is not quite there yet, but the concurrency support is far more advanced than anything planned for Perl 5.
> Yeah, I felt like there must have been a culture shift at Booking recently, because I spent the whole time at TPC::EU Glasgow last year without hearing a single pitch for hiring from Booking. Given that "Booking is hiring" been something of a running gag, something must be up.
Booking have changed their policy w/r/t sponsoring conferences and/or the "we're hiring" thing in the last 12 months. I know this as I'm one of the Swiss Perl Workshop organisers and they've sponsored us for the last few years, last year we couldn't get anything out of them and when we enquired we found out the reasons. I'll approach them again this year to see if the policy has changed again.
I don't know the exact reasons for this, and I suspect it's not a Perl thing but rather a change in management policy and/or the realisation that throwing devs at their systems is not the solution. Maybe someone read Brooks? I interviewed there several years ago and it seemed utterly bonkers that their dev team was > 100 given the nature of the business.
Anyway, to tie in with the grandparent post - we know that many banks in Switzerland are using Perl but they will absolutely not talk about it, nor sponsor us, nor send employees to the workshops. We know this as we have had private attendees who work for those banks tell us these things.
Perl was everywhere at one point, and by extrapolation that means it's still in an awful lot of places.
> It's not all that hard to hire competent and experienced Perl devs if you're willing to hire over the age of thirty, and remote (i.e. not moving to Amsterdam).
We're looking at the junior route, we've taken on 4 in the last 18 months and intend to continue this. We're at a point where new graduates were born after the Perl peak, so they don't have any knowledge of its decline in usage and/or preconceptions about the language.
I have a much simpler explanation. Publishers and conference organizers like O'Reilly eventually saturate the market for Perl books and conferences (books especially, because used books start to cannibalize their sales), so they move on to promoting a different, new language, so that even their existing customers will have to buy the new books and pay hundreds/thousands of dollars to attend conferences for the new thing.
I am not sure the total count of how many books O'Reilly published last year, but they have not exactly slowed down in releasing new titles: http://shop.oreilly.com/
In SF, maybe. But most developers in the world live outside of SV (for example, there are on the order of 1M C# developers worldwide). They don't write blogs, or even read them.
Developer outside of SF (outside of USA, in fact) here. I read blogs, have written them on occasion. Have worked with many developers in many non-SV locales. None of them read programming books, most of them read blogs.
I worked at Booking.com for a while, though never in Perl directly.
Take this with the grain of salt of any personal anecdote on the Internet, but I can definitely say that Perl is not loved there. Most people hated it deeply, some of them were like "it's not horrible...".
They are now allowing Java as well for the newer project, and they will have Java and Perl as 'blessed' languages moving forward. I don't really believe that they are doubling down on Perl in any sense of the word, they're just doing what any other company with a huge amount of code written in a dying language would.
I recently left a job at a company with a primarily perl 5 codebase. I would never choose to use perl to start a new project. In my opinion its relevance these days is primarily legacy systems and duct tape/scripting. I still use it for hacking on small tasks, it's pretty decent for technical interviews.
I programmed in Perl (5) in a large enterprise environment for five years. On a huge, monolithic codebase, with people who were innovating with the language in interesting ways. The business environment was restrictive (healthcare), but the amount of people leveraging Perl's flexibility to build powerful, flexible tools to enable faster development on the codebase at scale was startlingly high. A large proportion of developers engaged at every level, from XS to MOP (we used a modified version/fork of Moose) to distributed computing (we used a home-rolled queue worker solution, think Celery for Perl, but without the AnyEvent cancer), and novel web frameworks on the frontend, some of which were put back out on CPAN.
Basically anyone who wanted to be productive there demonstrated an impressively innovative, cross-cutting skillset that combined deep knowledge of UNIX technologies, the particulars of the application, and an incredibly expert language of the particulars of the language itself.
And honestly?
It sucked.
A lot.
I won't say this about any other platform--not modern security-vuln-in-the-package-manager-every-two-weeks JS, not "do you mean actually cross-platform or relying-on-compiler-UB cross-platform?" C, not the worst old-layered-on-new-layered-on-old-again PHP, but: Perl as a platform on which to build something non-tiny, or something that requires more than a small handful of developers, is unutterably awful. And I say that as someone that got pretty good at it, I think.
At the micro level, TIMTOWDI confuses newcomers, makes code review inconsistent, and means that as soon as someone feels fluent and productive on the codebase, then they have to engage with someone else's code, and they get stuck all over again. This means that mentorship is a complete bastard, and developer progression is incredibly hard to gauge, teams form fiefdoms (even in the face of huge linting tools; things that make an ultra locked-down JS/TS project look paltry by comparison--even for off-to-the-side greenfield projects) and can't transfer developers, you name it. Perl at any sort of scale is worse than the quoted "write-only" slogan: it's "write-once, re-learn from scratch on read". For a junior dev, rewriting would be a blessing.
At the medium (between micro and macro) level, the metaprogramming abilities of Perl just . . . fuck everyone up, no matter what they want to do. Want to get your work done in as straightforward and repetitive a style as possible? Welp, no matter how simple the task, and how straightforward-looking the utilities for it might be (on CPAN or in house), they won't interoperate for shit. Want to reduce boilerplate and ease the pain of common tasks by encapsulating (or, god forbid, applying metaprogramming) to speed up some process? No problem, first-class laws-of-the-universe-altering facilities are available to everyone--to get your change functional, you'll just have to interoperate with . . . well, everyone (some of whom wrote third party modules, and aren't people you can ask nicely for help). Object systems will fight with message queue clients for control over how calling nonexistent methods on arbitrary objects that neither one created should work (you thought Ruby's method_missing was a foot gun? Ha!). A tool for printing console logs will override the alarm(2) hooks used by your main HTTP client, meaning that if someone leaves a debug print in the wrong place, HTTP connections to a down endpoint will start blocking forever and kill you. Can this happen in other languages? Sure! Python, Ruby, and PHP (to some extent) all allow the same flexibility and low-level access. But only Perl makes this the default convention* to follow. I've heard people say "Perl programmers are just C programmers who couldn't hack it, but still want to write C". There's a grain of truth to that. Problem is, those aren't the kind of people I want to share a codebase with.
At the large (5MMSLOC+ codebase) level, Perl's an operational nightmare. Thanks to all the ways that libraries can customize the language, it has the metastasized version of most other interpreted scripting languages' problems when it comes to compilation phase and memory, namely: "what happens when I have to compile a huge dependency graph on startup? Can I cache those things in some sort of intermediately usable format or do I have to wait many minutes to start a test script? Can I fork? When I fork, what gets shared? Just filehandles opened by the application? Or random shit inside libraries too (and are compiled dependencies encouraged to make their IO resources' lifecycles manageable by the outer runtime)? Will my box crash due to GC-caused refcount/allocation cycles if all my forks exit at once?" These aren't unique to Perl, but I think they're worse in it than any other language. Oh, and that's without getting into the insane degree of mutability Perl permits. It's the freedom of C without the discipline ("set environment vars any time you want! Hell, they're a first class language data structure! Oh, and change what the STD* streams point to, that's fine to. And dynamic scoping and Scope::Upper means you can't tell when something will change because some code totally unrelated to yours decided it should!"). When trying to handle requests or do anything "nested" (terminate SSL, alter things that would go on e.g. "Context" in now-unpopular Go idiom), Perl's conventional answer is just "dynamically overwrite globals!" In general, this means that it doesn't matter in what context you tested your code in, it'll do something different at runtime because a) if it does anything interesting it depends on global-ish state, and b) other random code can rewrite SIBLING global state whenever it wants (think Python, but if the convention were for any coder that got stumped about how to pass data around to just modify globals/locals/vars willy-nilly). Again, a risk in most environments, only actively encouraged in Perl.
I promise that wall of text isn't just specific-employer PTSD. I've been through CPAN code, negotiated with package maintainers, gone to conferences, tried to get a sense of how people are contextualizing these problems. And the impression I came away with is that the vast majority of the entire Perl ecosystem--from the practices understood to be desirable by programmers to the behavior of existing/hardened/public code--is overwhelmingly harmfully inaccurate, poorly-thought-through, and defended by the worst strain of cleverness-above-practicality (or "don't touch it, it works when you hold it just right and don't breathe" for incredibly simple requests) when challenged.
Perhaps at some point in the past this ecosystem reflected the cutting edge, but I think that time is long past. If you're making a small commandline utility or personal one-off in Perl, go nuts. I don't think you're a bad person. Just make sure it doesn't get any bigger than one developer's worth of code.
EDIT (probably the first of many, because essay): typos and grammatical fixes. Promise I won't change the substance.
* Why the hell are either of those libraries calling alarm(2)? Answer: the logger didn't realize that write(2) wasn't interruptible, and the HTTP lib author didn't realize that connect(2) took a timeout. By the way, both were in incredibly popular modules on CPAN.
We worked at the same company, can confirm. Every problem mentioned above is true.
I once wrote a sub at this gig that returned a list (because hashes are lists) containing a string built by sprintf, which contained a sub dereference wrapping a sub that returned a string built by sprintf. Though it was necessary at the time I'm still just really, genuinely sorry about that. I guess the takeaway is that perl reverts even the most civilized devs to utter savagery.
>> Perl at any sort of scale is worse than the quoted "write-only" slogan: it's "write-once, re-learn from scratch on read". For a junior dev, rewriting would be a blessing.
Rewriting is really risky too; global state is problematic in any language that offers it but the almost complete lack of guarantees provided by the language is exhausting and makes it difficult to reason about even the most trivial change. Imagine being dropped into a 5k line function that hasn't been touched in 10 years. There are no tests, few comments, and the author quit 6 years ago. What types can this function return? Is it always called with all of its expected arguments? Where is it called from? None of these questions can be answered trivially. You'd think grep would handle the last, but you'd be wrong because people can and do build identifiers piecemeal as strings and eval.
The casual use of evals and symbol table manipulation in probably any large perl codebase only became more terrifying as I became more comfortable with the language. I cried a little bit when I figured out how the import system is cobbled together, and not exactly for its elegance or simplicity.
On the bright side, building healthcare systems with perl made me a very disciplined and defensive coder. It also got me used to saying things about my code like "reasonably confident" instead of "it works". Software engineering is so much more exciting with assumptions and guesses, who doesn't like to roll the dice every now and then? Now if I could just remember what all the runtime flags do...
To me it just sounds like your colleagues were a little nuts. You don't need metaprogramming to write a large application, and reaching for Devel::Declare should be reserved for last resorts and "hold my beer" moments. You're right that the conferences have a lot of this kind of stuff, but most of us know better than to actually use it, and read Perl Best Practices.
Most of these issues are solved in Perl 6. Any language changes are scoped lexically by default (e.g. declaring sub infix:<==>). Emphasis on threads instead of forking for concurrency, with await and first class Promises. If you want to write see, just write normal C and use NativeCall, instead of writing in the bizarre XS dialect of C. But it's kind of a different language... yeah.
I'm not going to say we weren't all nuts... but a lot of advanced language features, including metaprogramming, were necessary to build things that other communities take for granted: frameworks, test harnesses, mocking, static analysis, etc.
For major soft dev projects, Amazon deprecated Perl 12years ago when they moved to java for retail website development, and uses it for maintenance of too-big-to-fail legacy parts of the retail website.
