It's a feature, not a bug, that the language has remained stable and backwards compatible all this time.
I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded.
I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself.
I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
OTOH there are a couple of Perl tools that I still use (or whish I'd still be able to use), and I'm grateful those exist and Perl 5 is being maintained: Norman Walsh's SGML DTD documentation generator, the old citeseer code base (infinitely more useful than it's today), Debian's apache a2enmod/a2ensite management tools (that I've partly rewritten in shell) and apt tools. I even wouldn't hesitate to use RequestTracker tools (ticket management over mail) today even though it might not scale all that well.
The first version of PCRE was released in 1997, first Perl that supported PCRE in 2009. Claiming PCRE is "a legacy of Perl" is like saying C is a legacy of C#.
Calling a2p "aggressive" because it did a surprisingly good job converting awk to perl is like saying useful technology is aggressive.
Perl wasn't supposed to replace awk. It was designed to integrate features of C, shell, sed, and awk into one tool. That was spectacularly useful.
Perl is a high point in PL stability, still correctly running most Perl 4 scripts from the last century, with active community support for versions of Perl from 15 years ago. This is despite continuous evolution, eg adding Unicode support, in contrast to POSIX ("printable ASCII characters, space, BEL, backspace, tab, carriage return, newline, vertical tab, form feed, and null").
"Perl used to introduce ... sigills all the time in dot versions." Perl has never introduced a new sigil.
Perl maintains backwards compatibility despite also evolving because it's maintained by smart and conscientious professionals.
The OP discussion of the future is a continuation of that same philosophy.
I agree with that general sentiment in some respects, but:
> No nice http framework like Mojolicious for one
Cro is still in beta but it's nice and popularly used as an equivalent to Mojolicious.[1]
> not enough libraries to get stuff done.
One can write:
use Library::Foo:from<Perl5>;
in Raku to use Perl libraries via Raku's Perl Inline.That is to say, Raku can use tens of thousands of mature libraries from CPAN.
Stefan Seifert, creator of many of the Inlines, is using Catalyst in Raku in a production setting as part of his "battle hardening" work for the Perl Inline.[2]
(If Cro didn't exist, I daresay some folk would be using Mojolicious in Raku as well.)
> Pdf support is still quite lacking in Perl for instance.
I don't use Perl much these days but I'm surprised you're saying support is lacking. Metacpan lists over 700 PDF packages, so presumably something like a few thousand PDF modules. Are you saying they aren't up to the task of churning out a nice looking report?
In the meantime, David Warring's suite of PDF modules for Raku are highly capable.[3]
And the ability to use modules from other PLs in Raku isn't limited to Perl, even if it's currently smoothest for using Perl libraries, so one can use PDF libraries from, say, Python.
Raku performance is decent enough where it has to be, and continues, slowly, to improve. I would be seriously surprised if cpython outperformed it, and python gets used quite a lot in the same domains.
Wrote a poller last year for a bunch of baudion devices to tell me the current configuration of them, outputting as a csv (for version control) or webpage (for nice formatting).
It's basically configure an array (qw//) of IPs and snmp strings, run some snmpwalks (not gets as the oids can change depending) - if it fails try the second IP, pull out the useful data, mangle it a bit, then output
code like my $locM = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip sysName`; my $locR = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $resip sysName`; and
if ($ver =~ /SR1/) {
$eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.2.0`;
$eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.3.0`;
} else {
$eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.0`;
$eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.1`;
}
and my $cmd = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip 1.3.6.1.4.1.22425.10.5.3.5.1.$oid_rxip`;
foreach (split(/\n/, $cmd)) {
next unless (/.../);
next if (/0.0.0.0/);
s/[" ]*//g;
$srcs->{$_} = 1;
}
and
if ($mainip eq $resip) { $alert .= "NO SECOND IP"; }
if ($locM ne $locR) { $alert .= "Sysname Mismatch"; }It does the job, it doesn't rely on external language-specific libraries like Net::SNMP which complicates portability. There no doubt far nicer ways to do it, but my process involves
* Prod device to get original information using things like nmap, curl, snmpwalk, etc
* Mangle retrieved information to infer extra information
* Present information
Perl allows me to get from my prodding to useful output in minimal time, going from initial results from prodduing, to functioning output, in well under an hour.
Python could probably do something similar, but things like
/([0-9]*)kbit.*([0-9]*)kbit/;
my $inBit = 1000*$1; my $outBit = 1000*$2;
Is lovely and quick to type up for me compared with something like inBit = 0
outBit = 0
matches = re.match(".*([0-9]*)kbit.*([0-9]*)kbit/, line);
if (matches):
inBit = 1000*(int(matches.groups()[0]))
outBit = 1000*(int(matches.groups()[1]))
Ultimatly I don't care about elegant resuable code, I care about the results (a page telling me the bitrate on the stream, or that a destination IP has been changed or whatever)