Why did Perl never maintain its popularity?
Meanwhile, Perl was being badmouthed by people who couldn't handle its flexibility and thought it was unreadable and unmaintainable. But that wasn't the main issue, after all PHP was worse in those two respects, yet it flourished.
Perl 5 and 6/Raku have as much in common than Perl 5 and Ruby have.
It was not. For many years it was advertised as the next version of Perl (with the intent being perhaps a Perl 5.10 release and then no more major releases with the 5 version number), then years later a "sister language", and then finally now (but not retroactively) a "completely new language in the Perl family".
Very early (2000) the goal was for Perl 6 to be a rewrite[0]. There's no way this would have been a 5.x, especially given how the Perl 5 parser works and the class of warts that were aimed to be addressed:
> Perl 6 To Be Complete Rewrite (But Not What You Think)
> Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.
> The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it.
Quickly, being free from backwards compatibility gave room to try stuff out, and given the length of that design process, this resulted in features that they found out could be immediately useful if backported in some way to Perl 5:
> First, Perl 5 isn’t going anywhere. If anything, the rate of patches and changes to the code has increased. Cleanups from Ponie and the Phalanx project continue to improve the design and implementation, and new features from Perl 6 are making their way into Perl 5.
> Second, the opportunity to do the right thing without fear of breaking backwards compatibility opened up a lot of possibilities for impressive new features.
Granted, there's the following bit in the 2000 post:
> have a clear and automated migration path, which may include a backward compatibility mode
But back then (ca 2002-2005) I was only a Perl apprentice and a very junior developer yet it still struck me that the discussions highlighted differences that were expansive and fundamental enough that "next version of Perl" meant Perl 6 would be to Perl 5 what e.g Mac OS X† was to macOS 8/9 and (in retrospect since that happened only later) significantly different in class from e.g Python 2 to 3 or MRI to YARV.
That was my perception of it anyway; probably they weren't entirely clear what was the actual goal, hence a lot of bits were open to interpretation, and it got refined and bounced back and forth around a general baseline direction over 5-10 years.
[0]: https://developers.slashdot.org/story/00/07/19/203221/larry-...
[1]: https://www.perl.com/pub/2006/01/12/what_is_perl_6.html/
† which had classic mode to run the previous one's apps
Perl is just one big game of code golf. There is absolutely an entire era of developers who looked at that and ran far away (and I do not blame them at all).
With respect that's just not true.
Perl's sheer flexibility means there's a gulf between baby perl and good complex perl during which the developer doing the learning tends to make a complete mess (I definitely did this for a while) and some people never get past that stage so a lot of pre-existing perl code is awful and much though I love perl myself the language is definitely at least partially to blame.
For newbies, not having have to write the "magic" string,
print "Content-Type: text/html\n\n";
And the PHP standard library has quite a few things built in and combination of MySQL as LAMP was the hot word then, so I guess that's how it got traction and perl was gone from the web development.
I do like the Unix heritage of perl though. It does make you feel like a hacker when it feels the language has the shell syntax half baked in.
print $q->header();
However, if you are saying no one should use CGI.pm, then I agree. That module is a bloated mess. Much more efficient ways to use CGI without that thing.
It is usually installed by default on most Unix and Linux systems. It also rides along with most MinGW-based toolkits like Git for Windows. If you do software development, there is a good chance you might have Perl installed and not even know it.
Some people like to make fun of it despite its wide-spread use and utility. Most of them probably know little to nothing about Perl and have not written or maintained any Perl code. There is a good chance that they are using Perl code without knowing it.
Yes. All of the Amazon retail web sites used Perl Mason running on Apache mod_perl:
Well, that and CPAN…
It's still missing those :)
(To be clear for people unfamiliar with Perl, it probably will never have them, because it doesn't need them. In Perl, all functions effectively have a single parameter of array type. The standard convention is to assign each array entry to a variable at the start of your function definition, and the names of those variables then effectively act as parameter names. But that's just a convention and you can do something else if you want.)
use feature 'signatures'
use v5.36All new features must now go through an experimental phase after the smartmatch debacle. Signatures stayed in experimental status a little longer than most new features due to an unfortunate change with respect the order of function signatures and function prototypes. Provided you weren't using prototypes (which you almost never need) then they've been largely stable since 2015.
Most distro's under current support ship with at least Perl 5.24, so you can use them almost anywhere.
@_
@_____
@________
<wow, this thing is long>
_____________
<success!>
Also, CPAN is considered one of Perl's strengths. How did CPAN cause Perl to burn out?
My recollection of CPAN - and we are talking a really long time ago now - but it was just very much the same kind of dependency hell that we now have with NPM. In fact now that I mention it, I think there are strong comparisons to be made between Node and Perl. CPAN was great until it wasn't, and after a while - in my experience - it was mostly not great.
So for the best part of the naughties, people said things such as "don't bother learning Perl 5, Perl6 is coming"... Then the 2010s came and people got on the RoR and PHP and Python trains in the meanwhile instead.
https://www.slideshare.net/eflorac/perl-presentation-2013-pa...
Rinding high is something of an overstatement: The Big Thing at the time was Java, and PHP was already chewing away at Perl's market share. Some people thought the writing was an the wall, hence the mug-throwing incident that launched the Perl6 effort...
* It has no concurrency primitives that are anywhere close to other popular languages
* Tooling is good and works but is archaic, slow, and cumbersome
* The community hasn't positioned itself to be anything other than lightweight backend services and small webapps (smaller than rails)
* The community isn't really all that inviting or fun to be around
I can switch between writing async/await based $other_language and
use Mojo::Base -signatures, -async_await;
async sub url_body ($self, $url) {
my $tx = await $self->ua->get($url);
return $tx->res->body;
}
(the -async_await feature flag is powered by p3rl.org/Future::AsyncAwait which works fine with p3rl.org/Future and p3rl.org/Future::Utils as well as p3rl.org/Mojo::Promise in a single process - and since p3rl.org/Mojo::IOLoop and p3rl.org/IO::Async will share an event loop I often find myself using things based on both since it's all await-able)
p3rl.org/App::cpanminus plus p3rl.org/Carton (or my p3rl.org/App::plx) doesn't tend to be archaic or cumbersome to me (classic CPAN.pm, sure, but since cpanminus and plx are both distributed as p3rl.org/App::FatPacker bundled script s via github you can bootstrap them without ever loading CPAN.pm) - I generally find it less of an aggravation to deal with than most other languages' approaches (go's isn't bad at all, but e.g. virtualenv is very much not my cup of tea).
As for slow, the main thing that makes installation from CPAN slower is that our tooling tends to run tests by default - I'm aware that these days "verifying your dependencies actually work at install time" has gone out of fashion in favour of faster installs, but if you're happy with that trade-off pretty much everything has a 'notest' flag available.
So, basically, adding new keywords to perl via CPAN is a first class citizen and has been for over a decade now and we've gotten pretty good at it in that time (see also http://p3rl.org/Object::Pad - which has acted as a proving ground for a lot of the ideas that have gone into Cor - for another good example) and while I wouldn't at all object to F::AA eventually migrating into being a core feature, from a user POV it would just mean a slightly different 'use' line and maybe a few percentage points' speedup.
As such, I personally believe that while I understand that some environments have unfortunate issues with having dependencies, every other reason I've heard articulated for treating a keyword module as an inferior bolt-on as compared to a core keyword has proven unsupported in actual use.
Generally I code to (a) core perl only, mostly for one-liners embedded in shell scripts and occasionally for really small stuff, (b) pure perl dependencies only so I can easily deploy a single file with App::FatPacker or no file at all with Object::Remote, and (c) this project is best done using XS stuff and I'm willing to accept the trade-offs.
I'd note that Future::AsyncAwait itself sits in an interesting middle-ground because with a little help from my http://p3rl.org/Babble source transformer (needs more documentation though the current release manager has improved a lot of things over the 'just enough to do what I needed at the time' I originally released) I wrote http://p3rl.org/PerlX::AsyncAwait which rewrites most F::AA using code successfully to pure perl for fatpacking, at the cost of you ending up with an implementation that's mildly bizarre at first look and will be substantially slower on microbenchmarks.
(I say 'most' because I presume there's at least one bug and I'm certain that F::AA has added support for additional perl syntax constructs since that I've not gotten around to going back and adding yet, but so far in the situations where I want a fatpacked async/await using script badly enough PerlX::AsyncAwait has worked well -enough- overall that I've yet to feel the need to give it an overhaul even if I'm happy to admit it would probably benefit from one)
except regex handling which is still somehow way more awkward in other languages.