Let's not forget that Perl 6 was announced because Perl 5 usage was already stagnating. Perl 6 was supposed to fix that problem. But it ended up making it worse.
370 karma · joined August 17, 2011
I think the backwards incompatibility was a minor issue compared to how long it took for Perl 6 to be released. It was eighteen years from the announcement to the first (just barely) usable release. And for a lot of that time, I was hearing tech leads say things like "we don't want to start this project in Perl 5 if Perl 6 is just around the corner."
At some point, they changed the narrative from "Perl 6 is the next version of Perl" to "Perl 6 is a sister language to Perl" - but they should have renamed it at that point instead of waiting another 5 years.
It's worth remembering that the Perl 6 project was started because Perl usage was stagnating. But the project was so badly managed that it killed off both Perl 5 and Perl 6 (now renamed Raku).
What does that mean? Perl's basic OO support (using blessed hash references) was introduced with Perl 5 in 1994. I have no idea how anyone would even attempt writing OO code in Perl 4.
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.
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.
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.
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).
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.
But O'Reilly's interest in Perl waned and it sat, moribund, for several years (which probably explains its lack of Googlejuice).
A few years ago, the Perl community approached Tom and he let them take over running it. The team behind the PerlTricks web site ported over all the old articles and had been posting new ones. It had become a pretty useful resource again.
So, yes, it would be a shame to lose it. But from what brian has posted elsewhere on this thread, that seems unlikely to happen.
I'm getting reports that the PDF looks horrible in various Linux PDF readers. I'll see what I can do about regenerating it using more standard tools and fonts.
Yes. That's the point I was making.
That's not going to fix Centos 6 and 7 - both of which are mainstream in the web hosting industry right now.
And I've had this conversation with the Red Hat Perl packagers. They can't see the problem.
> The RPM packaging is (also IMHO) more rational.
To be clear, I also like the way that Red Hat splits the Perl RPM into individual RPMs for each module. My argument is only with the set of these RPMs that are installed alongside the main perl RPM.
> Who uses web hosting these days anyway, when you can fire up a cloud instance and install whatever you like?
Not you and me, of course. But I'm talking about people with no technical knowledge who rent some cheap web space and run a CGI guestbook program.
We could just ignore them. I suppose. Let them all switch to PHP. To be honest, I think most of them have already gone down that route.
The discussion is at http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms... if you want the full details. But ultimately, I think they decided that having the module in the core was tantamount to a recommendation for its use.
And, yes, it's easy enough to fix that (pointing that out was one of the main points of my article). But we're talking about low-end web hosting services where the web site owners don't have the root access to do that and the service providers either don't know what is missing or don't care about Perl enough to bother fixing it.
The point is that the standard perl RPM does not contain everything that you would expect to see in a Perl installation. And whilst I agree that it is simple enough to fix that situation, many people running low-end web hosting services don't realise that the standard Perl installation is stripped back and don't do anything to rectify this - as demonstrated by the example in my article.
I really don't mind Red Hat providing a standard stripped-down Perl RPM. I just wish they had called it "perl-minimal" or something like that, saving the name "perl" for the full Perl RPM.