I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?
I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs.
Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later.
I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project.
One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.
I was curious and you made me check. There's a number of releases with incompatible changes listed if you google for it. For example a whole list at https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-... So no, there's been quite a few.
Yes, most of them relatively minor though, which is why the OP has never stumbled across one.
(I found one once-- it turned out one coder had invented his own hash slice syntax. It wasn't supposed to work, but it did, until a particular upgrade...).
In general, Perl has been traditionally committed to backwards compatibility, but not fanatically so-- there is a deprecation cycle that can be used to remove the more problematic things.
It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility.
So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.
I'll note that if you use a strict subset of Perl, and write it well, with lots of unit tests, it's bearable to use. But it falls massively short when it comes to anything concurrent or async. And if you stray into the "clever" subset of Perl, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.
Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers.
Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
Yeah, this is the thing... it's very very easy to go down a one-way street to an endless hell of incomprehensible line-noise code and "clever" tricks that are incomprehensible and unmaintainable.
On the plus side, having dealt with the hell of "clever" perl early in my career (and, ahem, maybe having been guilty of writing some), it has beaten into me the absolute necessity of writing the simplest, clearest, not-clever code possible. In some other language.
Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop. If you need parallelism, yes, you'd better use Go or something else.
And the 10 years old bugs are to a large extent an exageration, because those modules are probably abandoned and you shouldn't use them anyway.
My experience with all of these has been that they've been frustrating to work with, and general support for them in the broader ecosystem is lacking and mutually incompatible.
> those modules are probably abandoned and you shouldn't use them anyway.
Yes, that's the point, the ecosystem is now lacking because of the number of abandoned modules (even for quite common stuff).
AnyEvent is harder because it uses closures everywhere but it works really nicely otherwise. It's not endorsed by some in the Perl community because the author insists that it doesn't need a license and chooses to develop it and track bugs on his own infrastructure. EV is developed by the same author and it requires a compiler, it can be plugged into AnyEvent. They're both very good quality.
IO::Async is a different event loop brought to you by the people that do not endorse AnyEvent but are involved with Perl 5 development. I haven't used it, but it has a large number of active bugs on RT, plus past criticism from the author of AnyEvent.
There's also POE which we use but it's possibly on life support and you probably wouldn't want to use it unless you want to live in callback hell, so I fully understand your frustration if you've actually tried it. We use POE in a critical part of our infrastructure and has worked fine, but that part is quite frustrating to maintain. Futher criticism of this event framework could be found here:
https://metacpan.org/pod/AnyEvent::Impl::POE
As a sidenote, I'm curreny working with Ruby's Async:IO which is a breath of fresh air compared to other event loops that I've worked with in the past.
Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications.
(Raku on the other hand has some extremly convenient CAP features in general.)
Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.
What about Docker and Virtualenv? Both make it possible to keep running code until the end of times.
For example, two years ago I wrote a small (50 LOC) Perl script to convert between two text format. On Unix you could install it by just putting the one file in /usr/bin. It would run in less than 1 ms, which was critical because it was repeatedly invoked by another (legacy) program. It was mostly a bunch of regex so it was natural to write it in Perl (or awk maybe but I don't know awk).
The python equivalent would have been at least 30x slower, significantly longer, less portable etc. Using docker just for this script would have been overkill. The only real alternative IMO would have been to make a statically compiled Go or Rust binary.
Whereas with Perl it's easy: any UNIX system (and I do mean UNIX in a wide sense, as I've run perl on systems like HP-UX, Solaris, Unicos, IRIX and others) will normally have perl5 installed and you'll be able to just run your software. If it doesn't have perl5, installing it is usually very easy and you don't have to deal with horrors like the python2->python3 transition.
I disagree. Perl still works fine for large systems. I understand why people choose other languages. It depends on what your needs are and what skillset works best for you and those you work with.
Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.
And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.
But I'm not arguing Ruby is well past it's peak - that is (sad, to me) fact because I happen to think it's a gorgeous language but it is what it is. I guess I'll have to get used to Python/Node or maybe switch to low level which is an old and perhaps unrealistic old dream of mine.
Were you around for the first (pre-2000) dotcom boom? From where I was sitting (freelancing in London) it sometimes seemed that all of the first wave of dotcom companies were writing their apps in Perl.
In fact, I've often thought that a lot of Perl's current bad reputation stems from this generation's CTOs and dev managers being people who suffered writing those Perl web apps at a time when no-one knew how any of this stuff was supposed to work and careful design went out the window in the rush to get things to market before the bubble burst.
IME, big older companies have Perl code chugging along, but not very visible. Part of this is also because there's the perception that it is hard to attract developers if the company mentions Perl any where in the job description.
IMDb.
Exactly, the second wave of dotcom software was largely written using frameworks that built on the mistakes we'd been making in the first wave.
And because, so many programmers had memories of horrible experiences trying to beat Perl/CGI applications into submission, it was probably too late for Perl even then - although a large number of excellent Perl tools (Catalyst, DBIx::Class, Template Toolkit, Moose, PSGI to name just a few) were emerging at about the same time as Ruby on Rails or Django.
(Having said that, I suspect that the Ruby community's love of "first, install a Ruby version manager" does it no favors when it comes to adoption for these sorts of small projects, although the same is arguably true of Python.)
[1] http://www.masonhq.com/sites
Edit: I left in 2013 so I don't know if it's still the case.
a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work.
b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough
c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.