tech

Perl is dying quick. Could be extinct by 2023.

thehftguy46 Comments

Some personal reflections about the evolution and death or programming languages.

By the forces a circumstances, I had to reverse engineer and decommission a few Perl scripts in an old company earlier this year.

That makes one wonder about who else is still using Perl? if any? Can’t remember the last time I’ve heard about it.

What is Perl?

If you want to see the numbers right away, scroll down to the next section.

For the young readers who may have never heard of it. Perl was a popular programming language about 30 years ago.

  • COBOL 1959
  • BASIC 1964
  • C++ 1985
  • Perl – 1987
  • Python – 1989
  • Delphi – 1995
  • PHP – 1995
  • JavaScript – 1995
  • Java – 1996
  • C# – 2001
  • Ruby on Rails – 2005

Having used many languages over decades, more or less professionally (C, C++, Java, python, Haskell, Ada, PHP). Perl is truly unique in that it is genuinely unique and exotic.

For example, it doesn’t support functions with arguments, well, not like what exists today in mainstream languages. It’s also based on an extensive use of symbols whereas today’s languages are more about letters (keywords, variable names, function names, etc…). I think it’s fair to say that Perl is about magic symbols that do stuff, so much that 93% of random characters are valid Perl programs.

Here are some sample cgi scripts in Perl, Python and PHP for comparison. Straight copy/paste from perl.com and stack overflow. Can you understand what they do?

Plot-Twist: Stack overflow answers never work and this time is no exception. Can you find the bug(s)? (answer at the end)

Source: https://www.perl.com/article/perl-and-cgi/

#!/usr/bin/perl
use strict;
use warnings;
use CGI;

my $cgi = CGI->new;
my %param = map { $_ => scalar $cgi->param($_) } $cgi->param() ;
print $cgi->header( -type => 'text/plain' );
print qq{PARAM:\N};
for my $k ( sort keys %param ) {
    print join ": ", $k, $param{$k};
    print "\n";
}
# PARAM:
# foo: bar

Source: https://stackoverflow.com/questions/3582398/getting-http-get-arguments-in-python

import cgi
import cgitb; cgitb.enable() # Optional; for debugging only

print "Content-Type: text/html"
print ""

arguments = cgi.FieldStorage()
for i in arguments.keys():
     print arguments[i].value

Source: https://stackoverflow.com/questions/2160382/how-do-i-grab-all-parameters-from-a-url-and-print-it-out-in-php

<?php
foreach($_GET as $key => $value){
    echo $key . " : " . $value . "<br />\r\n";
}
?>

What was the bug?

HTTP headers MUST be separated by \r\n line ending.

These scripts do a basic print() generating a \n only when running on Linux. The output is thus invalid, although there is a chance the CGI server is robust to that specific issue. Note that PHP doesn’t expose raw headers and avoid this class of issues entirely.

Stats

The below charts show programming languages popularity relative to one another. Data from Google trend.

Most Common Languages

Link to Google Trends: Perl, PHP, Python, Java, C++

Interesting finding from this chart, Perl was somewhat popular 2 decades ago, on-par with C++. Certainly popular enough to be considered among the major programming languages at the time.

Perl has been on the decline for a while. It’s reaching zero market share on this chart, what you’re seeing from 2018 onward is a single pixel as google trend is rounding up a near-zero value.

I think it’s fair to say that Perl can be considered a dead language. Definitely not something to use for new projects.

Niche Languages

Let’s compare Perl to other niche languages with low adoption.

Link to Google Trend: Delphi, Haskell, COBOL, Perl, Rust

Well, still more popular than COBOL!

COBOL: A programming language running on mainframes used by financial applications. Specifically designed with support for integer arithmetic, transactions and records. Often considered legacy but really hard to migrate from because of how large, old and critical the typical application is.

Delphi: A programming language and IDE, based on Pascal, like C++ is based on C. Designed to write desktop applications. The IDE had a GUI editor to drag and drop widgets, very efficient and easy to use, maybe the first to provide that. There’s a good story on how it came to be eclipsed by C++, C# and Java over 20 years.

How about Perl for a new project. Isn't perl more dead than cobol. Perl is dead.
Meanwhile… in a Perl conference.

Lifetime Projection

Curious what’s dying faster between COBOL, Delphi and Perl? Let’s find out.

The graph below shows the linear and the polynomial trends for each programming language.

Note that both regression curves happen to overlap for COBOL. A stable and predictable language indeed.

If we are to believe the linear projections, Perl could be extinct by 2023, a few months after Delphi. COBOL would outlive both by far and go on to 2030.

Of course, languages don’t go “extinct”. Maybe think of it as having order(s) of magnitude less developers, up to a stage where there’s really not much left. Typically those making/selling the language/tooling will be among the last to know about it, as well as a few curious googlers.

All unmaintained software “decay”, because of hardware and software evolution, up to a point where it “suddenly” stops working and it’s “unfixable”. For example, the executable doesn’t run on Windows 12 or Ubuntu 24 for whatever reason, looking into it, turns out the compiler doesn’t run anymore either, ouch.

Software lifecycle is coupled to the lifecycle of the platform it’s developed with and runs on, so there is strong risk associated with little used or divested platforms.

When will Perl go away?

Perl and Python have always come pre-installed on Linux. If I remember well, there was actually a Posix specification or something that had it as a requirement.

Times have changed though and they’re both actively being removed from major OS.

Apple has announced officially that all interpreters are deprecated (Perl, Python, Ruby) and will not be available with the OS in the next version of MacOS.

RedHat has announced officially that python is not setup out-of-the-box in RHEL 8 and future versions.

It’s only a matter of time before other distributions follow. The next logical step is for Perl to go away, the only question is when?

Apple announcement: Future versions of macOS won’t include scripting language runtimes by default + discussion on Hacker News
RedHat announcement: Python in RHEL 8

Conclusion

If you’re thinking of learning Perl or starting a new project in Perl, you might want to reconsider.

Nothing personal with Perl. Just doing stats.

Next, need to figure out which one took longer to build, Microsoft Windows or the Great Pyramid.

46 thoughts on “Perl is dying quick. Could be extinct by 2023.”

  1. “One of the first programming languages.” Wow. That kinda dismisses about 30 years of programming language history before Perl, and at least a couple of dozen major languages, including LISP, FORTRAN, Algol, BASIC, PL/1, Pascal, Smalltalk, ML, FORTH, Bourne shell and AWK, just off the top of my head. Most of what exists in today’s common (and even not-so-common) programming languages was invented before Perl.

    That said, I know you’re arm-waving the history here, and those details are not really part of the point of your post. But I do have a few comments on the meat of your post.

    Perl is a bit punctuation- and magic-variable-heavy, but is far from unique in being so. One example I just happened to be looking at today is VTL-2 (“A Very Tiny Language”) which, admittedly, ran under unusually heavy memory constraints (a 768 byte interpreter able to run not utterly trivial programs in a total of 1 KB of memory). This uses reading from and assignment to special “magic” variables for various functions. X=? would read a character or number from the terminal and assign it to X; ?=X would print that value. # was the current execution line; #=300 would goto line 300. Comparisons returned 0 or 1, so #=(X=25)\*50 was, “If X is equal to 25, goto line 50.”

    Nor is Perl at all exotic if you look at its antecedents. Much of its syntax and semantics are inspired by Bourne shell, AWK and similar languages, and a number of these ideas were even carried forward into Ruby. Various parts of that style (magic variables, punctuation prefixes/suffixes determining variable type, automatic variable interpolation in strings, etc.) have been slowly but steadily going out of style since the 70s, for good reasons, but those also came into existence for good reasons and were not at all unique to Perl. Perl may look exotic now, but to someone who had been scripting on Unix in the 80s and 90s, Perl was very comfortable because it was full of common idioms that they were already familiar with.

    I’m not sure what you mean by Perl “[not supporting] functions with arguments”; functions work the same way that they work in other languages, defined with sub foo { ... } and taking parameters; as with Bourne shell, the parameters need not be declared in the definition. It’s far from the only language where parentheses need not be used to delimit parameters when calling a function. Further, it’s got fairly good functional and object-oriented programming support.

    I’m not a huge fan of Perl (though I was back in the early ’90s), nor do I think its decline is unwarranted (Ruby is probably a better language to use now if you want to program in that style), but I don’t think you give it a fair shake here.

    Nor is it its decline, along with COBOL and Delphi, anything to do with age. Consider LISP, which is much older, arguably weirder, and yet is seeing if anything a resurgence of popularity (e.g., Clojure) in the last ten years.

    Liked by 1 person

    Reply

  2. There are many languages indeed. Speaking from a career-wise, professional perspective here. It could be quite difficult to make a career today out of those.

    About functions. What I mean is that Perl doesn’t do functions with arguments like current languages do. “func myfunction(arg1, arg2, arg3).”
    It’s correct to say that Perl has full support for routines and parameters, it does and even in multiple ways, but it’s not comparable to what is in mainstream languages today.

    Like

    Reply

    • Of course Perl supports function arguments. I think since 2015. It is in official documentation: https://perldoc.perl.org/5.30.0/perlsub.html#Signatures

      I can understand, that you don’t like Perl as a language, but it doesn’t mean you should write misconceptions about it.

      Personally I think Perl won’t go anywhere. Nobody wants to rewrite existing scripts that are used by system tools, ie. dpkg utilities in Debian or Linux kernel profiling stuff. As a real scripting language for basic system tasks is still good enough and probably you won’t find better replacement.

      And nobody uses CGI module from Perl in 2019. Really.

      Liked by 1 person

      Reply

    • I see by “functions with arguments” you mean specifically call-site checking against a prototype. By that definition you can just as well argue that Python and Ruby “don’t support functions with arguments” because they also don’t do do call-site checking against prototypes in the way that C and Java do, instead letting you pass a string to a function expecting an integer and waiting until it gets however much further down the call stack before generating an exception.

      “Dynamic” languages all rely to some degree or other on runtime checks; how and what you check is something you weigh against other tradeoffs in the language design. If you were saying that you don’t like the syntax of sub myfunction { my ($arg1, $arg2, $arg3) = @_; ...} as compared to def myfunction(arg1, arg2, arg3): ... that would be fair enough, but going so far as to say “Perl doesn’t support functions with arguments” is at best highly misleading and at worst flat-out wrong. Particularly when Perl does have prototypes with more call site checking than Python or Ruby do, albeit as part of a language feature for doing things that neither those nor any other language you mention support.

      In fact, many languages even deliberately provide support to remove parameter count checks and get Perl’s @_ semantics. Python programmers regularly use def f(*args): ...; C uses the more awkward varargs.

      And again I reiterate (perhaps more clearly this time): Perl was in no way “genuinely unique and exotic” when it was introduced; it brought together and built on a bunch of standard language features from various languages that anybody programming on Unix above the level of C in the 80s and 90s was already very familiar with.

      Also, I forgot to mention this in my previous comment, but neither Python nor Perl have ever been required by POSIX (or even mentioned by it, as far as I know), nor did Python always come pre-installed on Linux distributions. Also, it seems unlikely to be a “matter of time” until Python gets removed from the default Ubuntu install since Snappy and other Canonical tools are written in it.

      There are plenty of folks making a career out of Clojure, which is one flavour of LISP, these days. According to your metric, Google Trends, it overtook OCaml years ago, and seems to be trending roughly even, which is better than Haskell is doing.

      Liked by 1 person

      Reply

  3. >It was in fact one of the first programming languages, there weren’t many back then.

    I like how you skip Lisp, Smalltalk and C to show that Perl was one of the first. It wasn’t.

    Liked by 2 people

    Reply

      • I think it’s not the lack of an exhaustive list that’s bothering me, Maxim and probably a lot of other people, but that Perl in no way should be described as “One of the first programming languages.” It appears around half-way through the total history of “higher-than-assembler-level” digital computer programming languages to date, and after the large majority of major programming language innovations.

        That said, since the article has been updated, there’s no more issue with that. (Though it might be worth considering noting your edits so people understand that the comments here are actually quoting an earlier version of your post.)

        Liked by 1 person

        Reply

  4. “Perl was a popular programming language about 30 years ago.”

    Perl first appeared 18dec1987, which is 31 years and 10 months ago. The top of its popularity was between 1994-2000, hundreds upon hundreds of books were written, having Perl on your resumé would almost certainly get you hired.

    About 30 years ago, Perl 3 was released. Perl 4, released in 1991, Perl 5 in 1994. Popularity of Perl started to rise with Perl 4 and exploded with Perl 5. So, not “about 30 years ago”, but “about 25 years ago”.

    You stated:
    “It was in fact one of the first programming languages, there weren’t many back then.”
    Curt J. Sampson’s explained splendidly to you how wrong your statement was, and he did not even make a complete listing of programming languages that existed before Perl came to life. Your reaction was curt and not the apology it should have been.

    I am doing Perl since 1994. I am not a very good programmer, but I’ve done quite some marketing, and with the name Perl I have gotten a lot of very large clients in my days as a “devop” (well, in the nineties and begin of this century, it was of course not yet called devops). And I know of an immense amount of companies still using Perl. I guess you just meant to hurt Perl-people, as many other peopele did before you. After reading your first two mistakes, I realise I am not going to be hurt or offended or worried, I just shrug. Perl’s demise has been prophecised quite often, even almost 20 years ago.

    Liked by 2 people

    Reply

  6. Not sure if you’ve read the CGI article on Perl.com fully, but literally in 2nd paragraph it states:

    “Warning you probably don’t want to use CGI for modern web development, see Why Not to Use CGI.”

    As someone who has used Perl for about 15 years I have no dispute with the claim that it is dying, and much as I love it, Node and Python have some significant advantages, particularly for new programmers.

    I dropped using CGI for any projects over 10 years ago, around the time Mojolicious.org came on the scene. I have used ExpressJS, Django, Flask and other modern web frameworks, and for building modern web projects Mojolicious easily holds its own, despite the smaller teams behind it.

    Like

    Reply

  7. The programming languages time line is a bit wrong. Java was released in 1995 *before* JavaScript was release (also in 1995)

    Like

    Reply

  8. You linked to an article about random paint splatters being valid Perl programs. Did you notice the article is dated April 1, 2019? I’m not sure it was meant to be taken seriously. Or perhaps I’m just missing your joke.

    Like

    Reply

  9. Many complained about that Perl CGI article at the time [https://www.reddit.com/r/perl/comments/9wfgtf/perl_and_cgi/]. There are much more sensible ways to go about it [http://blogs.perl.org/users/grinnz/2018/11/modern-perl-cgi.html], and usually the better option is to avoid CGI altogether regardless of language.

    Like

    Reply

  11. Since v5.20, function arguments work like any other language if you want.

    sub foo ( $text, $other, $stuff ) { }

    You spent a lot of time collecting often disproven, trite, and frankly out of date arguments agains Perl into this article. Why the axe to grind? So much wasted energy bashing other languages.

    As for your argument that Perl is dying and should be avoided for new projects, it is especially specious. Many projects use Perl, will continue to use Perl, and as long as the Perl developers continue to release new versions of Perl, it is not dead or dying. Much innovation continues to take place, but since you so concerned with “popularity” trends, you are missing much of what is happening in this space.

    For those you might be influenced by this article, I encourage you to do your own investigation. Perl may not be right for you or your project, but please don’t base your decision on this straw man argument.

    Liked by 1 person

    Reply

  13. Your supposed bug isn’t actually a bug.

    $ perl -MCGI=header -e’print header(-type => “text/plain”, -X_foo => “bar”)’ | od -c
    0000000 X – f o o : b a r \r \n C o n t
    0000020 e n t – T y p e : t e x t / p
    0000040 l a i n ; c h a r s e t = I S
    0000060 O – 8 8 5 9 – 1 \r \n \r \n
    0000074

    The header() function does the right thing and inserts the correct line end characters.

    Liked by 1 person

    Reply

    • The article asserts that the examples from stackoverflow had the bugs, in other words the Python one, not the Perl one. Although the implication that the scripts “only do a basic print” might be the author assuming there is a bug in the Perl one, which is obviously not the case if you look at the source for the module in use here – which goes to great lengths to support doing the correct thing across a very wide range of operating systems.

      Anyway, there’s potential for a good article to be written about the decline of Perl(‘s relative popularity) but this one is not it. This is just another bait and switch (“Of course, languages don’t go “extinct”.”) with some shallow research to pad it out a little. In other words, the kind of stuff the web laps up.

      HFTGuy: Next time do better.

      Liked by 2 people

      Reply

  14. The core languages has exactly what you’re talking about since 2014 in v5.20 https://www.perl.com/article/72/2014/2/24/Perl-levels-up-with-native-subroutine-signatures/ The “experimental” status was reset due to a change in that spec. But it’s there for anyone who wants to use it.

    Good signatures and typing have also been available to anyone who cared post the Modern Perl movement. Since 2009 Function::Parameters https://metacpan.org/pod/Function::Parameters was available using more formal extension mechanisms. Something like Moose (2006) https://metacpan.org/pod/Moose or Moops (2013) https://metacpan.org/pod/Moops are equivalent to typing in Python 3 with signature support.

    This article is poorly researched on at least expressing the functionality available and *used* by anyone writing Perl today. I have no idea where you found the CGI example but Perl 5.22 (2015) *removed CGI from core* for the express purpose of stopping anyone reading an article like this, and thinking it’s how anyone should or would implement web code in Perl. Just look at the examples here instead https://mojolicious.org/ notice the -signatures one especially!

    Please stop creating this kind of content, it’s a large factor in the “demise” of Perl. People on the outside trying to pick at the carcass for some cheap traffic via Hacker News. Speculating on the demise is fine, but your utterly outsider reasoning of why is definitely not on point at all. This article is describing Perl from 10-15 years ago at least if not 20. Certainly not the kind of Perl a software engineer in a startup is producing today.

    Liked by 2 people

    Reply

      • You are confused about the difference between HTTP and CGI; these are two different protocols.

        The CGI 1.1 specification from 1996 very clearly says in section 9.2, “Parsed Header Output”:

        The script may return any other headers defined by the HTTP/1.0 specification [3]. The server must translate the header data from the CGI header syntax to the HTTP header syntax if these differ. For example, the character sequence for newline (such as Unix’s ASCII NL) used by CGI scripts may not be the same as that used by HTTP (ASCII CR followed by LF).

        Like

        Reply

      • Yeah, I told them at the time that publishing a CGI.pm article in 2018 was a stupid idea.

        And perl.com is run by a small group of Perl enthusiasts; it hasn’t been in any way “official” for a very long time.

        Like

        Reply

  15. “Perl was a popular programming language about 30 years ago.”

    Well, I don’t think it became really popular until CGI programs took off in the mid-90s.

    “For example, it doesn’t support functions with arguments, well, not like what exists today in mainstream languages”

    Take a look at the “Signatures” section in any recent version of “perldoc perlsub” and you’ll see that your knowledge is out of date. https://perldoc.perl.org/perlsub.html

    Not that any of this tiny niggles invalidate your main point.

    Like

    Reply

    • Perl was immensely popular amongst those of us doing Unix sysadmin from the late 80s through about 2000 in applications that had nothing at all to do with the web. It was a big improvement over using combinations of Bourne shell, sed and AWK.

      Liked by 1 person

      Reply

  16. I like Perl and I’m gonna keep using it, probably for quite a while. There are lots of new tools for Perl, like Mojolicious, and lots of old and still good modules. I’m sorry that you don’t like it!

    Liked by 1 person

    Reply

  17. Perl is very much alive for me, and here’s why.

    I process a daily extract of employees and assignments with tables in the high hundred-thousands into the single-digit millions.

    This desktop task started with Microsoft Excel, something of a nightmare 64-bit version notwithstanding.
    We then migrated parts of it to Microsoft Access, better but still with severe limitations. The complexity of calculations on tables with many thousands of records were blowing the doors off those two application. I ported the work to mySQL.

    All great, except for the occasional special character or random corrupt line fed to us by the corporate accounting system. Enter perl: Rather than use mySQL’s primitive tools for discarding lines, I condition the input files with perl one-liners that process one file at time, called from a Powershell script.

    The perl code processes the entire stack of input files in about two minutes. The regular expressions syntax took awhile to master, but I find that regex is gaining a foothold everywhere, from mySQL to text editors (and not just vi). The “one-liner” solutions in Perl were just what I needed: compact, easy to revisit after a long time (unlike a page of code), and lightning fast.

    I could do this in Powershell directly, you say? Yes, but it turns out the Powershell processing time is between 10 and 50 times that of Perl. Maybe there was a way to optmiize the Powershell, but the regular expression evaluation was atrocious compared to Perl.

    For text processing of large files on a Windows desktop–admittedly, not a most common need–Perl is a viable soluton. If it lasts 5-10 more years, I’m good, as hopefully I’ll be playing shuffleboard between my Medicare doctor appointments.

    Liked by 1 person

    Reply

    • Bill, while that’s a classic application for Perl, it’s not an argument to use it in this decade (or even perhaps the last decade) when we now have significantly better languages that can do the task just as well (or perhaps even better), such as Python and Ruby. Perl in its time did a brilliant job of moving “scripting” languages forward, but other languages have taken up the baton and moved well beyond it.

      The only reasons to use Perl for a new project these days are because you have better nearby support (from yourself or others) for it than you do for another language or because there’s some rare library that Perl has that other languages don’t, and it’s not more practical just to port the library.

      Like

      Reply

  18. I don’t think the conclusions hold, I think the linear data model isn’t predictive of reality, even though these are presented as objectively, I doubt Perl will “stop being a thing” in the next 10-15 years.

    Liked by 1 person

    Reply

  19. People have been writing “Perl is dying” articles longer than many modern languages have been around. But guess what? It’s still here. Nevertheless, I’m sure your article will be vastly popular by everybody that knows very little about Perl but are happy to believe that their chosen language is superior without actually verifying the facts.

    It is interesting that people are searching Google for “Perl” less and less. But I think it’s a bit of a stretch to correlate language popularity with the frequency of searches on Google. You’ve taken a piece of data that says one thing, reinterpreted it to mean something completely different, and then stretched out your reinterpretation into a forecast for the future and then turned it into a flashy clickbait title. Throw in a few colorful graphs, and people will be citing your article without any critical analysis in no time.

    Liked by 1 person

    Reply

  21. Perl lives on in regular expressions since Python and other languages adopted Perl expressions – really the best part of the language (if you ask me). I’m still running a couple regEx heavy programs at least a few times a month – and will install ActiveState Perl on a new Windows machine tomorrow so I can continue to use them. For what it’s worth, Perl was THE server side web language 20 years ago. That’s about when PHP started to get popular – because the learning curve was lower and simple things were simpler. (My old PHP code is much harder to maintain because PHP sucked so much back then it seems like half the language has been deprecated. Old Perl still works.)

    Liked by 2 people

    Reply

    • You make a remarkably good point: Perl totally upped the game as far as regex standardization, capability and awareness was concerned. A whole generation of programmers became familiar with regex (mostly for the good!) and it lives on in the large number of PCRE or equivalent implementations – Java, Nginx, R, etc – which really moved the ancient Unix regex to a new level. If Perl is dead, long live that legacy!

      Liked by 1 person

      Reply

  22. You’re also neglecting many advanced features like Moo/se, web frameworks that still drive profitable large scale businesses and probably the best ORM – DBIx::Class. Basically sounds like you came across those bad old scripts no one maintained for 15 years and dug up some stackoverflow stats to vent the Perl anger that the untrained monk succumbs to (lol!). Much like COBOL Perl probably won’t go away. To learn Perl if you’re new – probably not a good idea true, but it won’t die or go away.

    Liked by 1 person

    Reply

  25. So, MUMPS isn’t really popular, but it’s still used. I’d say Perl is still quite popular. It’s not Python popular or even COBOL popular. (I mean COBOL is popular, really.)

    But, Perl is popular.

    Perl has advantages as a systems scripting language for one thing. That’s why it’s installed in most UNIX derived operating systems as well as embedded in popular software products, i.e., Oracle and Git. Administrators tend to know “something” about it and many can program it. Systems engineers find it useful because it’s snappy, quick, and beats awk + sed hands down. It will be continually used for a long time. Besides, many websites are still written in it which seems to be important for some reason.

    And banks do use Perl. Some rather famous Wall Street ones actually. They just don’t tell you because that might offend the Python Social Justice Warriors–PC and all that.

    To me, I think secretly all these people really like Perl. At the very least they get a thrill out of using it. Rejecting Python can do that. I mean, who doesn’t want to fight against the Python ‘man’ whose claims to fame are he’s friendly to children and has data science libraries that are just shallow interfaces to well written C and C++.

    Liked by 1 person

    Reply

    • I don’t know what your issue with Python is. As someone who’s been using sh/awk/sed/etc. since the early ’80s, Perl since the early ’90s, Ruby since the early ’00s, and Python over the last few years, I can tell you that currently Python is clearly the best of the lot. You can see one way in which it’s better quite clearly by simply trying to write the core of pytest in your language of choice. Without the ability to hook into your language’s parsing system and get an AST you can manipulate before sending it off to be executed, you won’t be able to do things like assert [1,2,3] == f(g(h())) and have it take apart and display all the pieces of that (such as what h() and g(h()) returned, and what elements of the list differ) when the assertion fails.

      I assume by “Python SJWs” you’re talking about the people who say you should stop right now and rewrite your entire project in Python. They’re idiots, but every language and technology has them. The most important thing to have in any serious project is a deep understanding of your language and platform, and if that’s Perl and not Python you’d be insane to go for a big switch. Where you see there might be an advantage in another platform it’s worth spending time trying to convert bits, but you do that at first simply to get a sense of the costs and benefits of switching, and it’s quite normal to decide that it’s not worthwhile.

      …and has data science libraries that are just shallow interfaces to well written C and C++.

      You say that like it’s an unimportant thing, rather than a brilliant thing. There’s plenty of stuff that’s better done in a compiled language that can be made very machine-level efficient, and that includes a lot of data science stuff. But to say you’re going to write in C++ the parts that you could write times faster in Python (or whatever your higher-level language of choice is) with no real penalty in execution time is just dumb.

      And those interfaces are nowhere near as “shallow” as you think they are. Making sure your’e using the efficient C/C++ code for the parts where you really need a lot of performance, but still being able to use a much less efficient language for the other work, is tricker than you think; it’s easy to design an API that suddenly sticks you with having to move some processing up into Python unnecessarily and slows down things by a couple of orders of magnitude, or makes you go write C++ code to do trivial things that are nonetheless much harder to write in C++ than Python. A careful study of the pandas and numpy APIs would teach you a lot.

      Liked by 1 person

      Reply

  26. Perl 6 Killed Perl 6, so hard it changed its name to Raku.
    Perl 5 Killed Perl 7, Long Live Perl 7someday and Perl 5.38(?) with an upcoming experimental new class framework!

    “I’m not dead yet!” –Strange that the Monty Python joke is applying itself to Perl rather than Python.

    Like

    Reply

Leave a Reply