Perl5 -> Perl6 has been highly contentious.
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.
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.
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."
Only if you chose to write perl code in this way. The same could be said for many languages
That's what programming is.
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.
The only Perl I use these days is oooooooold software (MRTG) I guess with the exception of Spam Assassin and RT...
Anymore Grafana backed by InfluxDB w/Telegraf is my jam for the same general problem set (TIG stack).
RRD is pretty efficient so I don't have much need to change.
> 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!!
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.
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
{
}
I've seen a lot of negligently written code with broken windows on the surface, that deep down turns out to be criminally insane.
If somebody's doesn't give a shit enough to indent their code, they usually don't give a shit enough to design it either.
That's exactly why I've never mentioned Java on my resume (or in earlier times, Visual Basic) =D
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
Because it works. Scripts/software that works does not experience bit rot. As long as it works, people will continue to use it.
Edit: OK, fine. It seems the downvoters are convinced that the code does in fact experience bit rot, and spoils with time. Probably like fish.
Why don't you specify this single reason you allude to?
I think there are plenty of reasons, and they work to reinforce each other.
> 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.
Asking people to back up what they say is 'combative'? Nothing else in this post has a ring of truth either
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.
In 2010, that may have been true.
In 2019, I can only think you haven't looked around much recently.
I see you have not tried Mojolicious.
Why not? There are CPAN frameworks that make it a breeze.
The most efficent "modern" web development I have done has been with Perl.
Mojolicious, Catalyst, Dancer – take your pick.
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.
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.
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.
Perl was the popular language once upon a time ago. But it stagnated while new technology came in to replace the old.
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.
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).
However, for short log processing scripts, I've not found anything with even close to the same productivity.
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.
Which magic do you mean: supernatural, illusion, or fiction?
https://en.wikipedia.org/wiki/Magic
>Magic may refer to:
>Magic (supernatural), a set of beliefs and practices distinct from religion and science
https://en.wikipedia.org/wiki/Magic_(supernatural)
>Magic (illusion), the art of appearing to perform supernatural feats
https://en.wikipedia.org/wiki/Magic_(illusion)
>Magic in fiction, the genre of fiction that uses supernatural elements as a theme
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.
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.
It does the job
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...
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.