21–30 of 463 posts
Can someone give the rest of us some context on this?
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.
It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).
Earlier quoted context omitted.
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 compa…
Heh yeah, totally. 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).
Earlier quoted context omitted.
> FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011. 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.
Sure but there's a reason that development has moved off of Perl.
Why don't you specify this single reason you allude to?
Earlier quoted context omitted.
> FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011. 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.
Sure but there's a reason that development has moved off of Perl.
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.
This has been a huge deal for the Perl community. First, it was thought that Perl 6 would be the replacement for Perl 5. But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor. Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" fo…
This should have happened with Python 2/3.
Can someone explain to me, for what kinda of new projects would they use Perl/Raku in 2019 at all?
A lot of my colleagues in NLP and text processing still prefer to write in Perl. Granted they are mostly the old guard but it is prevalent in academic language technology research.