Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. Introducing a new language doesn't seem worth it.
You nailed it, but this cuts both ways: as the folks who used to do everything in Perl move out, the language fades. In the last few years I see that new tasks that would be done in perl several years ago are now done in python. I like perl, but I think its best days are over.
So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
That's where I learned Perl (along with getting familiar with Linux and Vim). I didn't have to use Tcl, but my team members had to. Based on our experience, we got a one-credit course started on these topics for our dept in college. These days they have moved on to Python though.
[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty:
https://medium.com/the-technical-archaeologist/hello-world-o...
Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for.
They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language.
If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain.
But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
I disagree.
"$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?)
"@" is understandable for a 6 year old.[2]
Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2]
[1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable.
[2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
perl syntax is actually highly intuitive because it copies nearly everything from pre-existing tools, shell scripts, sed, awk, and so on. perl just packaged it all into one cohesive tool.
It was one of those languages where you barely need to read the manual because you can predict things because the syntax will be exactly what'd you'd guess it to be.
All this, of course, if and only if you had previously grown up on shell, sed, awk and friends. For anyone who hasn't, I can totally see how perl seems like alien gobbledygook.
Short term? Probably.
Long term? Probably not.
At one point your _one_ Perl developer will disappear, and while you held onto that one person, the Perl language has faded even more into oblivion, making it literally _impossible_ for you to hire people to maintain your product.
If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
> to maintain your product.
Often with Perl it isn't the end product that is the issue, that is more likely to have been ported to some other language/framework, but instead all that Perl is managing IT and project infrastructure.
> If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
In my world, more and more companies learns from past issues/failures. They also live in the same world as you do, which sees a decline in both number of Perl programmers and a decline in general usage of the language itself.[1][2][3]
> Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
That was 20 years ago. Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
Welcome to earth! We don't do it that way here.
Correct. Longer if you count people in the 80s working to fix affected code that caused problems for 20-to-25 year term financial arrangements and so forth. I'm not saying it was recent, just this is a good example and one I don't think many have sufficiently learned from (too many think it was a fuss over nothing, when really it was a fuss to make sure it was nothing).
> Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
I make no claim that it is a good thing. Just that it happened, has happened far more than that one big event, and similar things will continue to happen at different scales.
I could (but for commercial and legal reasons, shouldn't and won't) name specific examples of companies relying on systems written in elderly languages/frameworks, apparently locked to old versions of software components or hardware that they just hope won't break before they finally get budget for something new (which isn't likely to happen for a reasonable definition of "soon" under the circumstances) because finding the right people to fix it would be somewhere between gloriously expensive and actually impossible.
It comes down to the number of people that knows, or shows interest in, any given programming language.
You are right that you might need to diverge from your language of choice at one point, even rewrite your whole application (which is scary enough), but you should do that at a point where a different language is "at top", or at least trending towards "the top."
Perl is trending downwards in all statistics,[1][2][3] except maybe statistics that has to do with salaries, because it's hard to find people who can do the job.
This is not a bashing of Perl itself: I love Perl, but I also see where it's failing, which is why I make use of several different programming languages to get a job done, if necessary. At the end of the day, Perl is just another tool in the toolbox, and as a boss you need to employ people that are familiar with the most popular (not necessarily the best, sadly) tools to get the job done.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
(Although it wasn't "perfectly functioning" Perl code but whilst it was an abhorrent mess internally, the actual problems were largely caused by the database parts - awful schema, bad server setups, godawful queries from an insane home-grown ORM, etc., which could all have been fixed in a couple of months.)
Ruby however seems to be as esoteric as perl - its not js or python or java in ubiquity, it's not loved like rust and go, it doesn't have the longevity of perl, c and bash. Perl5 has run, pretty much unchanged, for over 20 years, meaning no need to update my programs. Ruby on the other hand is a treadmill language. Code written in 2005 (when rails came out and it was the new hotness) wasn't runnable a mere 10 years later in 2015. I have processes that have longer runtime!*
Time will tell how long Ruby 2 lasts, but I'd wager that perl 5 lasts longer that ruby 2.
I'm interested in stable languages that just work for most of the things I write -- I want something to perform a task and carry on doing it with minimal effort for the next decade or two. I'm not interested in perl 6 or 7 because its a new language, it's competing in a crowded sphere other more recent languages.
Perl5's value is its constantness and ubiquity.
* hyperbole
One of my CLI tools that lives in $HOME/bin on every machine I touch, is perl code I wrote in 1990. Haven't changed it once since then, just keep copying it everywhere.
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>;
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`;
}
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;
}
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;
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]))
Is that the reason why there's a shortage of new NVidia cards? /s