In the same boat on the "why haven't people moved on"... Perl use to be ubiquitous but over time it's really gone to the wayside vs. Python tooling for more complex stuff, and back to basic BASH for the simple scripting needs.
Every time Perl comes up in a professional environment for me I'm reluctant to say I'm capable, because it's always a hacked-together mess from an engineer who's likely no longer with the company. (obviously this is VERY anecdotal to my career)
I dropped Perl from my resume about a decade ago because I just frankly don't want to work with it. The language is terse, and I don't think anyone who's starting off these days would be spending their time well by learning it. Make your own opinions, but mine is/has always been "ewww."
It’s the Perl culture, to do even simple things in the weirdest way possible and everyone will call you a wizard. Whereas the Python community praises complex ideas expressed as simple code and frowns on tricks. That’s why all but the the most obsessive have moved on. And from what I’ve seen Perl 6 takes it to the next level.
You pretty clearly have very little familiarity with "Perl culture" and even less with Perl6/Raku.
Perl 5 is in decline, no doubt. But it isn't because whomever you're visualizing when you wrote the above is an annoying nerd. People can and do disagree on the 'why'; I personally think it is the general decline of Unix-style syntax combined with the natural ebb and flow of language evolution.
If "what you've seen" is watching the compiler developers work through language design, the origin of your misconception at least makes a little sense, even if that's obviously a weird, unfair basis.
By all means, hate on perlmonks.org if you like. Just don't spread insulting nonsense.
It's unfortunate but that's the bread-and-butter of comment sections mentioning Perl (Perl 5 and Perl 6). And what's with "the most obsessive"? What's this supposed to imply?
In my realm I need things to be supportable by lots of people. I use languages that are modern + people want to use, I document like crazy, I use opinionated frameworks that have good track records, I need to hire engineers that can support the code I/others write, etc etc. I don't find your comment to be true, and will even go as far to say I've worked with very clean legacy code.
Tangential: If you look at any "popularity of language" studies Perl has been on a downward spiral for over a decade. Ex: https://www.tiobe.com/tiobe-index/perl/
I see "well that's just x" as a poor argument for, well... anything.
> it's always a hacked-together mess from an engineer who's likely no longer with the company.
Oh man, in 1996 I was at Nortel. Some Ms. C. in Computer Science (no longer with the company) left behind Perl cruft whose indentation levels didn't even match up:
whatever
{
}
type of thing. He didn't know how to operate a programmer's text editor.
I would rather deal with that than a project with millions of classes which are mostly empty full of useless comments that tell you nothing about how the project is put together.
> there should be a cryptocurrency based on Proof of Spam Assassination
Did you know that the blocking proof-of-work algorithm in Bitcoin today, derives from the Hashcash proof-of-work algorithm, which was originally designed to prove you are not a spammer!!
> I'm unclear why people continue to use Perl at all
Because there's a huge amount of applications and websites still built in it, and it's still a great language so new projects are written in it all the time.
source: my very prosperous career, which has been almost entirely in Perl for the last 15 years
I would argue that becoming "legacy" is akin to bit rot. Sure, it still runs, but everyone that knew how it worked has left the company, and it's written in a language that is no longer in vogue and will require specifically hiring people with that skill to maintain.
As a counterpoint, I think we can both agree that writing production software in one of the toy languages that pops up on HN frontpage every day is a bad idea. Writing in a language that is old enough that it has become niche has many of the same issues. It doesn't really matter whether the software is poorly understood because the language is new enough to be niche or old enough to be niche; the outcome is the same.
For people who are curious as to why people moved to Python. Some will say because college kids are taught Python, but I think that is a side effect.
Perl is an old language, pre OOP. It's a language from the 90s, when everyone was hacking together code not knowing what the future would be like. There is a lack of organization. Perl is like C in syntax, features, and in speed. Python is like C++. Every failing you can find in Perl stems from it being a PP language first, from dirty code to kids not learning it in college.
Raku attempts to address every failing of Perl, yet be better than Python. If it succeeds, who knows, but I hope it gets at least a chance to make something of itself.
People like easy to read languages. Many years ago, when I first got back into development, I decided to choose to learn Python or Perl. After doing some research, it seemed Perl was more widespread. But Python was easier to read, so I went that route instead(luckily). I think the popularity of Basic and Golang vs their competitors of the time help prove this point. People say that Go is only popular because of Google, but I honestly feel if Rust and Go switched owners, it would have played out the same way.
And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does.
Would I write an API in perl? Nope.
Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely.
Mostly because I will write a few hundred lines of code for existing CPAN modules to solve the problem that I have, letting me to move on to doing something else. I like boring tools that just work. In 99.99% of the times the tools/whatever you are writing is not inline, does not need to have amazing performance. It just need to work and be braindead simple. Perl excels at that. I still daily use code that I wrote over 25 years ago and modified it a couple of times since that point ( integrating git ).
Edit: Can't reply below so I will reply here:
Re: I would not write an API in perl.
> I see you have not tried Mojolicious.
I have seen it, tried it, got excited about it and immediately came to my senses because I asked myself "Why on earth would I build or advise people to build an API in perl? It is slow. It is bad for concurrency. It probably has a pile of corner cases that I'm or some other people are going to discover. If I need to ingest something via web I will throw a simple nodejs app. Millions played with it actively in a "web" sphere, and hit most of the corner cases. There are thousands articles on stackoverflow and we have dozens of skeleton servers that already have all the needed foundations, including federated databases that support live password changes, traffic sharding, online promotion and switches, dynamic reloads, do-at-most-once queues, do-at-least-once queues, etc etc. Why would I want to reinvent all of this when the job of the API is to get the stuff and if the question cannot be answered via a couple of lookups push the request to a worker?"
Re: CPAN in 2019
> n 2019, I can only think you haven't looked around much recently.
Maybe. I have not seen it to be the case two months ago.
I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl.
Yes, Perl's threading support is terrible, and I do wish it was as effortless as in Raku. But you'd be surprised how often you actually only need an event loop and non-blocking implementations, and for the rest of the time there's Mojo::IOLoop->subprocess or IO::Async::Function to provide a thread-like model with efficient forking.
> I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl
Because there have not been million people with different levels of skills poking and prodding Mojolicious into good, bad, ridiculous, disgusting, ugly and beautiful uses, posting on Stackoverflow, getting answers, getting smacked down, or getting those things marked as known bugs. I use code to achieve a business objective, not to create a beautiful code or use a wonderful framework.
Just framework itself is not enough - it needs to have skeletons for services that would handle common edge cases -- database failures with automated switch to standby, internal request queues with retries, configurable. Clean interface to external configurations that should be changeable in-flight without a restart; patterns for interfacing with other systems, etc.
> Yes, Perl's threading support is terrible,
Some of the basic crypto modules and modules that use those basic crypto modules are not thread safe. In 2019. Modules that were written a decade ago. I'm not interested in figuring out those bugs in production.
I wrote a pretty complex API using Dancer. I'm not going there again.
Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.
> That's just a saying, it doesn't mean that there's one specific reason
> a reason
Singular, in English that means there's a single reason.
> I think there are plenty of reasons, and they work to reinforce each other
Care to expand on this?
Genuinely interesting, a thread where people complain about a language and they are so careless with the language they use to try and get their point across...
Not particularly since you seem very combative... but here it goes, from the top of my head: without Moose/Moo etc OOP is (was? no clue, I don't follow development any more) just cumbersome and archaic (and with it you'll run into strange things when you hit errors), support in modern IDEs is lacking, there are few developers and therefore a smaller community, it's often not among the officially provided SDKs etc. Those are all interconnected. You can't easily hire Perl developers. Nobody wants to pay large sums to compete about the few there are to provide an SDK for a language that is on its way out. Nobody wants to work with a language that's not really supported by businesses. There's no large community to improve tools. Of course, I don't mean literally nobody, just very little. It's a vicious circle.
I liked Perl (it has a special place in my heart), I've written a ton of stuff in Perl, some of it I still support, but I can't say that I've missed it in the last five or so years since I've stopped actively writing it. I still occasionally log into the perl-focused community I used to frequent and they are still getting about a post a week. I never gave Perl6 a chance, simply because it would be a switch to another language where knowing Perl didn't really transfer, so I might as well go where the music plays. And yeah, CPAN-modules are nice and all, but a lot of it always looked to me as if written for a contest of clever code, not to be read & understood easily.
Modern web development doesn't use these, and mod_perl is certainly not recommended anymore - CGI still has its uses, but don't use CGI.pm. A modern webapp is written in Mojolicious or a Plack based framework, and they can all deploy transparently via a standalone server, or any PSGI or CGI server, or even mod_perl or fastcgi if you really need to.
If you do not build gigantic monolithic applications and instead stitch together lots of things that do just one thing each using jobs engines and APIs for injecting data and collecting data most of the worker updates become trivial - minutes rather than months. It becomes irrelevant if a worker is written in perl, python, C, java, scala, etc.
Genuinely curious - and not trying to be a jerk... but where do you find Perl fits well? I can only imagine needing it if I'm stuck on a legacy OS/strictly governed environment where it's the only option I have. (ie: governmental work etc.)
Oneliners that range from simple text processing to complex magic. Wonderful web applications in Mojolicious. Lexical scoping and strict variable checking. Four strong event loop ecosystems, futures and promises, and an in development async/await syntax all for collaborating asynchronous tasks. Great integration with shared libraries through XS and FFI. A consistent culture of documentation and testing for everything on CPAN. And mainly, familiarity with the language.
Perl is really great at text processing. Pretty much any kind. A lot of folks dislike first-class regexes, but if they're magic in a lot of contexts like this.
My second remaining use is experimental coding. It is probably about familiarity and experience (I've been writing perl since Perl 4), but I find it to be the most fluid, most "fun" language for noodling around and trying out ideas.
I use Python for things other people will have to work on, because it is the current popular kid, so most folks have at least seen it. Not because I especially like it - the GIL is still a performance killer, purity of essence arguments keep obviously useful things (like case statements) out, and (as I'm sure will be demonstrated shortly) there are always annoying people around to condescendingly tell you why you're wrong to want things like case statements.
In this case, it's a Perl concept related to DWIM (Do What I Mean), where the features will make practical assumptions about what you need to accomplish in their implementation, so you don't have to worry about the details. It can be abused (and is) but is also very useful for quick oneliners in particular.
Not to be confused with the Perl feature called magic, where functionality can be attached to a variable to affect what happens whenever it is accessed. Though this is often used to implement the former concept.
If it involves a lot of text processing, Perl tends to be either my first choice or pretty close to it. Perl's also surprisingly fast for an interpreted scripting language (especially when it comes to text processing). I've used it pretty heavily for system automation tasks, too, and thus generally continue to do so unless there's some specific reason why I'd need to use a different language (and usually there ain't).
I've heard that Perl's also massively popular in the genetics/bioinformatics world. I'm assuming a lot of their data is in textual formats, and thus would benefit from a language that's fast at processing that data. I have no experience here, though.
Not grandparent, but to me, Perl's niche is short log-processing scripts (like, 200 lines or fewer). Once it looks like it will either need an input other than a text file or grow to a significant length, I tend to rewrite in something else.
However, for short log processing scripts, I've not found anything with even close to the same productivity.
Brain dead workers. Ask what to do. Fetch the needed data. Do the thing with that job. Signal job completion or failure. Die. Wait for a supervisor to restart you for the next job.
Yep. Nowadays Erlang (or Elixir) would be my tool of choice for that, but before discovering those (or when that felt like overkill) a quick Perl script would be my way to go.
Incidentally, apply this to web requests/responses and you've invented CGI (where Perl was incredibly useful, even if PHP happened to be a bit more popular).
> FWIW: I'm unclear why people continue to use Perl at all
Great language, large library on cpan, great eco system, people enjoy using it, they have a large code base that's run fine for decades. Choose 1 or more.
> I moved on in 2011
You're right, it's all about you and what you do...
Hi, would you mind reviewing the site guidelines? I'm afraid your comments have already been breaking them quite a bit, and we ban accounts that do that.
The idea here is to post thoughtful and substantive comments, not aggressive ones, and to avoid the flamewar style, which degrades discussion quality and provokes worse from others.
Perl6 is basically a different language much to the chagrin of many Perl users. A lot of Perl users are entrenched in Perl5.
FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011.