I do know somebody who is using perl for a RESTful api backend for a line of business app. I was pretty fired up to find that, if only for nostalgia (haven't used it myself since undergrad studies required it [bioperl])
I started using Perl in the late 80s as a replacement to complex sed and awk scripts, but switched to Python in 2010. I still remember the day that mod_perl hit me, boom! Scaling inside Apache.. 1999 was a lifetime ago.
That's my primary use case for perl 'when it gets a little to complex for bash, just use perl'. Which is what perl was initially designed for. I never made the switch to python as it seemed to have more aspirations than that. I always thought that people who took perl further than 'great for sysadmin type tasks' were a little nuts.
What's the alternative to Perl for the sort of file conversion and text processing that can be done with a Perl script of about a hundred characters that I can type in and edit on the command line? Or if I want a 100-line script that will work in 2029 the same as it works today and won't require any stuff to be installed first?
I don't like Perl, but since it's there, it works, it runs quite fast and I'm familiar with it, I'll probably continue using it for my own stuff for as long as I continue to use a computer, which is likely to be at least a couple of decades beyond 2023.
I use it multiple times a week for printing/copying tabular data from space-delimited files. It's not the most arcane usage but it would probably take several lines to do what awk does in one. I don't even know much awk! Learning any bit of awk is worth every moment of the investment.
cat somefile.txt | awk '{ print $1 "\t" $2 }'
On mac I pipe to `pbcopy`. Saves me several minutes each time.
Also see basic Unix utilities like cut / paste (and colrm if your *nix has it, not sure if MacOS does) as these do the same column selection and printing and support simple options for delimiter and field number selection instead of writing a parser.
Having extensively used AWK and PERL, I don’t agree. AWK works for simple things, but has significant limitations especially for more complex parsing you might do in a dozen lines of PERL. Subroutines don’t return complex structures, Strict mode declaration checking, hashes, foreach style iterators are much less functional or missing in AWK. Multi layer structures are also trivial in PERL (hash table or array composed of child hash or array). Finally, AWK versus GAWK versus NAWK compatibility is an issue.
The problem of course, is that you have to be familiar with it. If you're facing this problem and don't already know Perl, you'll just use whatever your regular scripting language of choice already is.
Perl may be efficient at some tasks, but having to learn it to take advantage of that efficiency is basically never going to pay off.
For one-liners, awk. For anything more complicated, I'm faster writing a 30-line Python script than a 5-line Perl script - and everyone involved, myself included, is happier six months later when we need to edit it.
The use case you describe is a use case of diminishing value in an era of better IDEs and tools. Definitely a thing people can still want to do, but your average new hacker is likely going to lean towards a tool with fewer sharp edges so that they can be confident the file conversion came through correctly.
The question is whether future generations will be as familiar with it as we are.
An expert Perl user will always be able to show some nifty program that could never be replicated in another language, or would be ten times larger and full of bugs if it were. If you play to its strengths, it is amazing. There is no better language for ingesting text in ad hoc formats and generating formatted reports. Hence the name.
The Practical Extraction and Reporting Language thing is not Perl's name, it's just a backronym that Larry Wall came up with. My personal favorite backronym is Pathologically Eclectic Rubbish Lister (I say this as someone who really loves Perl).
It seems like you are arguing that because it is in the official docs, that is where the name 'Perl' came from, but that is not accurate.
autarch is right, "Practical Extraction and Report Language" is a backronym --the language was named 'Perl' first, and that acronym (and others) were devised later ( see https://en.wikipedia.org/wiki/Perl#Name ).
Larry was originally going to include the 'a' and name the language 'Pearl'. However, at the time there was already a programming language named 'Pearl', so he changed the name to Perl ( again, see https://en.wikipedia.org/wiki/Perl#Name ).
I didn't say anything about primarily. I mean I have languages I don't use anymore, except on the odd times when I know they're the best solution.
on edit: anyway I guess my point really is the language will not be extinct until the last human user of it no longer uses it all. I don't think it is gone within 4 years.
I just don't see a reason to use it nowadays. Python is more verbose, but it's also easier to read and debug, and its tooling and package ecosystem is less chaotic.
And for small stuff, I just have Zsh, which is a perfectly suitable Perl replacement.
> I used to write Perl but I do not take it out of the tool chest anymore and I see very few Perl codebases in the OSS world.
It's still haunting under the covers of many a proprietary app. It handles all the database processing for a fairly modern program I reverse engineered last year (so we could transfer from it to a new program without having to manually re-enter the 2.3million record database).
Heck it was only a couple years ago that macOS used Perl for string processing in libc. [0] (I believe it now forks to sh instead.)
The OSS world, all the glitter, is just an iceberg to the ice continent of the software industry as a whole. There is still a lot of new mainframe code written today. And a lot of glue scripts are still written in perl at various software houses
cPanel
craigslist (https://www.craigslist.org/about/thanks)
imdb (https://help.imdb.com/article/imdb/general-information/what-software-are-you-using-to-run-imdb/GH25HF4NB3C2KP9E)
Companies who use Perl within London http://london.pm.org/advocacy/
2018 sponsors (https://act.yapc.eu/lpw2018/)
2019 sponsors (https://act.yapc.eu/lpw2019/sponsors.html)
Saying that Perl was one of the first languages is silly of course. It's nowhere near as old as LISP, FORTRAN, and C.
However, Perl is the first of its kind. Prior to Perl, one would have to hack together in either Bourne or C-shell a series of commands all strung together, poorly. Grep, sed, awk, and a slew of utilities were strung together poorly with any specialized manipulations coded in and compiled from C.
Perl was the first popular language that gave us first class data structures (arrays and hashes) along with the programming structures we were familiar with in C. The inline regex support obviated the need for sed and awk gymnastics to the relief of many.
All of the crazy things in Perl that drive so many people nuts today were derived from the shell scripting that everyone was familiar with at the time. Error codes in "$!", that seems familiar, if you're used to /bin/sh. Perl's syntax which mapped shell script idioms directly into language features made these conversions a breeze.
Perl was the first and best at being able to convert these awful shell scripts into something which was maintainable. This was also Perl's primary downfall. Because it was so easy to use, lots of people who were not first-class programmers were able to write a lot of not-so-nice scripts which made later programmers sad and angry. It was a victim of its own success.
Calling it "extremely revisionist" is absurdly generous even. Calling it "one of the first" programming languages is just flat-out wrong. Lots of other languages were around for many years or even decades before: COBOL, FORTRAN, Pascal, C, Algol, LISP, just to name a few. The idea that Perl is "one of the first" is just plain insane.
having read the article I agree with only one point that the author makes: once Perl is removed from the default installs, it will lose one of its advantages, being there and working by default. People will likely shy away from installing an additional programming language.
The other topics there have been rehashed many times before and are little more than extrapolations and exaggerations - how could a language ever go extinct ... if anything COBOL demonstrates that languages do not go extinct.
> The other topics there have been rehashed many times before and are little more than extrapolations and exaggerations - how could a language ever go extinct ...
COMIT, TRAC, JOSS, FOCAL, and a few dozen assembly languages all would wave, but they're a bit dead at the moment.
I used to write perl 20 years ago and haven't touched it in 15 years. I thought it already was dead, then alas I got a job where it still exists in massive undisturbed quantities of thousand line functions and scripts with no structure.
It feels the same as the anthropologists must have felt when finding an Amazonian tribe completely untouched by the modern world.
Almost nobody was using Python in 1989 either. Clearly it's a mistake on the part of the writer and not some deliberate attempt at judging when a language became popular.
Thanks for clarifying. But that seems a bit unfair and arbitrary. Rails definitely boosted its popularity but Ruby itself is quite potent without it. Stripe has its systems written in Ruby without using Rails, for example.
If we apply the same standards for Python, shouldn't we track its popularity by when NumPy(Numeric) came into being? (1995)
This is supremely pedantic though, and I don't really care about arguing it here, so :shrugs:
Kind of stupid article. Perl will be dead because there are less searches on it and Apple is deprecating all script interpreters (not singling out Perl) and RedHat has announced that python is not setup out-of-the-box. Bold predication - in 2024 there will still be plenty of Perl running.
Although not AWK! Apple has to keep it to still adhere to POSIX (which is still a relevant classification to many big buyers in government and enterprise). Maybe this will cause an AWK renaissance...
The thing that RHEL is trying to fix is to prevent customers from being tied to the system python/perl and should install a version that works for them and the application they are trying to run. People installing random modules into the same perl/python as is used for system startup/critical software has always been a problem but it is also one of those things that makes having a long term LTS nearly impossible because you can't separate the user needs vs. the distribution needs and trying to fix anything turns into backports to weird ancient versions. This way distros can package and update the things they need independently from everything else and not disturb the user, and also provide a more comprehensive suite of packages that also don't disturb the system space. This is similar to how Amazon Linux is setup a bit.
A better example is a user I should be able to install python 3.7 and use it, even if the system libraries for the core packaging is based on python 2.x. Traditionally most users would just build their system scripts on python 2.x (because it is there), which means that if you upgrade the distro from RHEL X to RHEL Y (which brings a python 3.x) you break a user's environment. This was a constant problem when you were trying to go through the RHEL 5-6-7 upgrade paths among other things.
It hopefully will be resolving the issues of people and packaged software using weird old versions because it is there and breaking when something changes. My favourite example is having to write in ancient bash just to support MacOS which still ships bash 3 something.
In a shorter version, the interpreters are still there and buried, just not on $PATH and given to the user as a what they should use.
(This is opinion based on how I have seen people abuse systems and try to upgrade them over the years).
This article immediately reminded me of the classic "BSD is dying" meme. For those who haven't seen it yet, https://everything2.com/title/BSD+is+dying explains it, and several of the points listed there might also apply to this article: "[...] there is always someone who is more than willing to defend it", "easily knocked down facts", etc.
Ignoring the trolling aspect for a minute. There is actually a real discussion to be had on how BSD (or any software) continues to be developed and maintained, with support for current hardware
It takes a lot of work to keep software going, both developers and time. Wondering where it comes from. If it's free it's not getting money from users to finance that; if the user base is dwindling it also means there are few developers or other-company employees to work on it.
> That makes one wonder about who else is still using Perl? if any? Can’t remember the last time I’ve heard about it.
Perl, like many other languages, has its own bubble. I'm using Perl daily at work. I used Python for a while, but the Perl job market was just too nice to pass. I have a backlog of clients interested in Perl work longer than I can handle, and they don't mind my requirements because they have no one to replace me with.
Is that a sign of a dying language? Probably yes. But to be honest, if it's about to become the next COBOL then I'm looking at a lifetime of profitable work with little to no competition :)
BUT:
> Nothing personal with Perl. Just doing stats
Perhaps a little bit of research could help your point as well. The CGI example you mentioned is broken, but is also using a module (CGI.pm) that's been bad and wrong for so long that even Perl, with its eternal love for backwards compatibility has removed it from Perl Core. That's a sign of Perl's marketing problem, yes, but it's hardly a real indication of a language that's too old to care about fixing itself.
I have the same experience. A healthy portion of my time (25% is my estimate) comes from Perl freelance work. The amount of 'legacy' systems that run Perl and need maintenance is staggering.
If it weren't for the current Python hype (AI/ML and devops), I'd have more project that require Perl than Python.
I've not used Perl as my primary language in over a decade, but it remains my favorite.
I never used CGI.pm for generating HTML...the idea of using functions for tags seemed unneccusarily dense when HTML is a string and Perl is well suited to handling strings. Later I shifted to templating modules like HTML::Template and Template::Toolkit. I assume those are long defunct, but vfb the point is that they offered better functionality than CGI.pm
I have not used it but I have heard it is as lightweight as you want (in the sense that it may be huge but you only need to use the basics if that is all you need).
But it has been quite a while since I last used Perl for cgi.
>>> The CGI example you mentioned is broken, but is also using a module (CGI.pm) that's been bad and wrong for so long that even Perl, with its eternal love for backwards compatibility has removed it from Perl Core.
It's also the only example that could possibly make PHP look good, because it's the problem domain PHP was invented for. Nobody is innovating on Perl's CGI so it's not going to make use of any improved language features from the last 20 years.
Perl won't become the next COBOL, as COBOL only got that way because of the reasons outlined in the article: the financial sector used it extensively, and their systems are too mission-critical and they're too afraid to break things by upgrading.
Contrast with Perl, which was mainly used by niche hackers (in the original, respectful sense), used in the types of products that live by the SV valley motto of "move fast and break things".
> Contrast with Perl, which was mainly used by niche hackers (in the original, respectful sense), used in the types of products that live by the SV valley motto of "move fast and break things".
Umm, no, I think you have a very poor idea of what Perl was and is used for, and who used it. I imagine Perl is still in heavy use (if not heavy development) in the back-end of some Banks. Perl was also used to power many of the web circa 1999. Some of the big names that used it are Amazon and Craigslist. Perl was one of the main languages used on the internet pre-2000. Much has changes since then, but let's not rewrite history to completely ignore Perl's role in where we are today.
Amazon and Craigslist still use it. Craigslist extensively and ongoing. Amazon according to my understanding did something with a (rather crappy) perl templating language to compile it down to C++ in a similar way to what Facebook did with PHP to hack. My understanding is that's still in use, but probably not undergoing extensive development.
There's quite a lot of perl about. It seems to have a strong niche in accommodation booking platforms (booking.com and others), and recruitment software (ziprecruiter and others). As well as big chunks propping up various enormous companies (think banks and tech).
Perl lacks uniformity of syntax which is sort of a problem, but it does excel at helping to manage the mess that is real world problems.
Personally aside from getting sucked into ~ 30% devops over the last few years, I've had trouble finding decently paid work that isn't perl. Last time I got laid off I had an alternative offer within an hour.
Perl was great when it came out, but there's a lot of better alternatives available ("better" in terms of robust language definition and diminished likelihood of a typo leading to a sound-but-incorrect program, which seem to be two things that developers value more over terseness in an era where IDEs assist with editing in verbose languages).
I suspect perl will always have a place (there are a million shell scripts out there handling issues people need solved), but it'll have a place like COBOL does; useful where it already exists, but not something you learn until and unless you need to edit a perl script.
Modern IDEs make syntax addition cheap. One of the primary advantages of perl is its terseness, but that advantage diminishes in an era of IDEs converting a few keystrokes into a hundred characters of (better self-documenting) code.
This was mind-bending for me too. It seems like the author is just arguing that since the syntax is different it's worse? The flexibility in Perl is nice, and while references can be a real PitA, a weird assertion to just make.
One day my comment on the article might get approved showing that the syntax is also "modern" since like 2008! 2014 was formal support in the core of the language with `use feature 'signatures'` in version 5.20
There is no bug with `\r\n`. I checked the provided example, fixed `\N` to be `\n` (this bug causes a compilation error, so it would be noticed during compilation). The hex output is as follows.
In Perl, "\n" has a similar kind of platform-specific behavior like it does in some other languages (such as C). Its output is more or less defined as "whatever is appropriate on this type of machine". It's useful for printing for the console or writing to a text file that will be used on the local machine, but not for everything.
If you're building a message to go on the wire as part of a protocol that needs certain specific characters, and if you're trying to write portable code, then you shouldn't use "\n" (or "\r").
> All systems use the virtual "\n" to represent a line terminator, called a "newline". There is no such thing as an unvarying, physical newline character. It is only an illusion that the operating system, device drivers, C libraries, and Perl all conspire to preserve. Not all systems read "\r" as ASCII CR and "\n" as ASCII LF. For example, on the ancient Macs (pre-MacOS X) of yesteryear, these used to be reversed, and on systems without a line terminator, printing "\n" might emit no actual data. In general, use "\n" when you mean a "newline" for your system, but use the literal ASCII when you need an exact character. For example, most networking protocols expect and prefer a CR+LF ("\015\012" or "\cM\cJ" ) for line terminators, and although they often accept just "\012" , they seldom tolerate just "\015" . If you get in the habit of using "\n" for networking, you may be burned some day.
So, arguably it is a bug to write it that way, but not exactly a fault of the language since it is providing a facility to do something useful and also explicitly warning you against using it for something else.
One way to think of "\n" is that it's similar to localized strings. In both cases, you have a need to let the system render something differently depending on context (platform or user location/language/etc., respectively). It's helpful to have that abstracted away, but you should realize that magic is happening and that you generally shouldn't use it for machine-to-machine communication.
I love Perl. I first used it in 1994, around the time the early versions of Perl 5 were released. It’s hard to overstate what a breath of fresh air it was compared to the incumbent languages at the time, which were either very low-level (mainly C, and increasingly C++, at least in the Unix world) or else brittle and limited (various flavours of shell script, sed, awk).
Perl was a joy to use. Things that would have needed dozens of bug-prone lines of C could be done in just a few characters. Regular expressions and associative arrays were first-class language features! And, with the advent of Perl 5, there was enough scope for structuring code in a modular way that it wasn’t insane to write pretty large and serious programs.
The culture was delightful too. In those days it was centred on Usenet and mailing lists, and the general attitude was freewheeling and fun. When the first user group was set up in London, where I was living by then, I signed up immediately. That’s still the most fun I’ve ever had hanging out with programmers, and Perl was the glue that bound us together.
At some point I joined the developers’ mailing list (perl5-porters), just to see what they were up to. After a while I started to contribute: bug fixes at first, and later language features. That was fun.
So, Perl has been a big part of my programming life. But I haven’t really used it in anger for about 15 years. I still write Perl one-liners on the command line for ad hoc data processing, and actually I think Perl is still the best available tool for that, although younger coders tend not to be familiar with it any more.
But as for writing real programs? The world has moved on. There are newer languages that have taken the good ideas from Perl, but without so many confusing idiosyncrasies.
Perl 6 is another story, one that I didn’t have much part in. It’s a fun bundle of ideas, and maybe some of those ideas will spread and be useful elsewhere, but I doubt it will ever catch on itself.
I’ll always love Perl, but I doubt I’ll ever write another serious program in it – except maybe out of nostalgia.
Very poor stats if you're extrapolating the time a market participant will be reduced to zero by looking at relative market position without also examining absolute usage.
That is, it's possible for something to have less relative market position but be increasing or static in total usage if the total market is increasing fast enough. That doesn't indicate something is dying, but it looks the same in graphs, and extrapolating from those lines won't show you what you think it is.
Is Perl in that situation? Probably not that much (but somewhat, I would argue), but if you're going to make a case on statistics, don't do a crappy job of it...
I have seen absolute rubbish written in Python (which is supposed to be like pseudocode) and I have seen beautifally written Perl. It's 90% down to the individual writing the code. Perl just has a lot of syntactic sugar which can make it look like line noise to someone that doesn't understand it.
So the story goes. Care to relate some examples that show how it is worse than any other language?
I’ve seen mind-curdlingly horrible Perl of several varieties (novice, mad genius, and the biggest ugliest balls of mud you’ve ever seen), yet nothing has yet touched even the hem of the horrors I presented over-architected Java ravioli with acute patternitis.
I'm not sure using a very outdated CGI example as an illustration of why Perl is dying is all that convincing.
It says in the source article "you probably don’t want to use CGI for modern web development", then explains all the reasons why not, pointing you to modern frameworks such as Catalyst, Mojolicious and Dancer.
Not saying Perl doesn't have challenges with its popularity, but this isn't a very good case as to why it's dying.
It's just a basic example to show what the language looks like. Same in the 3 languages straight from the textbook and stack overflow.
Basic CGI script to show all GET request parameters. If you were writing an HTTP API, you would probably do something very similar although not running over CGI.
Ok but why not choose an example to show what the language looks like today, vs >10 years ago? Perl CGI is deprecated, so if anything using an example this outdated proves the opposite of your point.
Surely a more constructive comparison might be looking at a 1 page app in Mojolicious vs Flask, Express, etc?
Adding Bitcoin and Blockchain I was just curious. But imagine if I wanted to prove popularity by using 'last year in Hacker News' in titles. It would appear that Python was 'more popular' than Bitcoin or Blockchain.
No question it's less popular than it was years ago for numerous reasons. Not sure the methodology used (google trends) tells the complete picture.
Indeed, Perl does have named function parameters, the same as almost all modern languages - and I highly recommend using them.
(I use them throughout my code, except for modules that should stay compatible with very old versions of Perl.)
But folklore is a thing. Many people learned Perl before named parameters, and to be fair they took about 20 years to arrive (and are still called "experimental"!). People don't like to change now.
I think most people writing new Perl code still use the no-named-arguments idiom, just because it's old and familiar. Which makes code look more arcane than it needs to, to outsiders, unfortunately.
I really like perl. I started writing it in my university for sys/admin stuff and then went down the rabbit hole and investigated most of the nooks and crannies of the language. I like all the special symbols. I have no issue with reading code that I wrote five months previously. I like that it does not limit what I want to do programmatically.
In fact I recently snuck some perl code into production at my company a month or so ago: we needed an android app to post data to a backend where it could later be analyzed. Super simple. I wanted to get it out the door as fast as possible and due to the fact that it will be retired before the end of this year, I choose to write the backend in perl using MongoDB and Mojolicious. Then I saw that MongoDB is retiring their driver for perl[1]. I still went forward, but it was yet another reminder of the state the language is in.
It saddens me that perl does not get more love. It is a fantastic language but I can not justify teaching others it, or encouraging them to learn about it.
164 comments
[ 2.8 ms ] story [ 180 ms ] threadPerl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon-- he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
----
But seriously, Perl 5.30 just came out in May. It's not dead yet.
I started using Perl in the late 80s as a replacement to complex sed and awk scripts, but switched to Python in 2010. I still remember the day that mod_perl hit me, boom! Scaling inside Apache.. 1999 was a lifetime ago.
I don't like Perl, but since it's there, it works, it runs quite fast and I'm familiar with it, I'll probably continue using it for my own stuff for as long as I continue to use a computer, which is likely to be at least a couple of decades beyond 2023.
cut -d’ ‘ -f 1,2 < some file.txt
Perl may be efficient at some tasks, but having to learn it to take advantage of that efficiency is basically never going to pay off.
Or put another way: https://xkcd.com/1205/ and https://xkcd.com/1319/
This is generally what formal education is supposed to solve.
Btw: The book "Perl One-Liners" from No Starch is not bad for people who want to learn a bit of Perl to become "dangerous".
The question is whether future generations will be as familiar with it as we are.
https://perldoc.perl.org/perlform.html
"""Perl officially stands for Practical Extraction and Report Language, except when it doesn't."""
autarch is right, "Practical Extraction and Report Language" is a backronym --the language was named 'Perl' first, and that acronym (and others) were devised later ( see https://en.wikipedia.org/wiki/Perl#Name ).
Larry was originally going to include the 'a' and name the language 'Pearl'. However, at the time there was already a programming language named 'Pearl', so he changed the name to Perl ( again, see https://en.wikipedia.org/wiki/Perl#Name ).
This can be verified from multiple sources, including the "Learning Perl" book ( see https://en.wikipedia.org/wiki/Perl#cite_note-57 ).
I guess that depends on whether you consider an obviously tongue-in-cheek backronym to be "the official name". We obviously disagree on this point.
The -n option processes lines, the $_ magic variable yields from STDIN:
outputs "foo\nbar\nbaz"The -p option processes lines and prints the output:
outputs "my string"Just using -e allows you to pull all of STDIN with gets:
is functionally equivalent to the last.More references: https://www.notch8.com/bash-commands-ruby/
on edit: anyway I guess my point really is the language will not be extinct until the last human user of it no longer uses it all. I don't think it is gone within 4 years.
I used to write Perl but I do not take it out of the tool chest anymore and I see very few Perl codebases in the OSS world.
And for small stuff, I just have Zsh, which is a perfectly suitable Perl replacement.
It's still haunting under the covers of many a proprietary app. It handles all the database processing for a fairly modern program I reverse engineered last year (so we could transfer from it to a new program without having to manually re-enter the 2.3million record database).
Heck it was only a couple years ago that macOS used Perl for string processing in libc. [0] (I believe it now forks to sh instead.)
[0] https://news.ycombinator.com/item?id=18920122
Ditto the busybox shells on a million embedded systems, but I guess that's a bit beyond most here.
Nothing like a full answer to your question:
https://metacpan.org/recent
Alas, not nearly so active as it used to be, but still a fair amount of activity.
However, Perl is the first of its kind. Prior to Perl, one would have to hack together in either Bourne or C-shell a series of commands all strung together, poorly. Grep, sed, awk, and a slew of utilities were strung together poorly with any specialized manipulations coded in and compiled from C.
Perl was the first popular language that gave us first class data structures (arrays and hashes) along with the programming structures we were familiar with in C. The inline regex support obviated the need for sed and awk gymnastics to the relief of many.
All of the crazy things in Perl that drive so many people nuts today were derived from the shell scripting that everyone was familiar with at the time. Error codes in "$!", that seems familiar, if you're used to /bin/sh. Perl's syntax which mapped shell script idioms directly into language features made these conversions a breeze.
Perl was the first and best at being able to convert these awful shell scripts into something which was maintainable. This was also Perl's primary downfall. Because it was so easy to use, lots of people who were not first-class programmers were able to write a lot of not-so-nice scripts which made later programmers sad and angry. It was a victim of its own success.
The other topics there have been rehashed many times before and are little more than extrapolations and exaggerations - how could a language ever go extinct ... if anything COBOL demonstrates that languages do not go extinct.
COMIT, TRAC, JOSS, FOCAL, and a few dozen assembly languages all would wave, but they're a bit dead at the moment.
It feels the same as the anthropologists must have felt when finding an Amazonian tribe completely untouched by the modern world.
If we apply the same standards for Python, shouldn't we track its popularity by when NumPy(Numeric) came into being? (1995)
This is supremely pedantic though, and I don't really care about arguing it here, so :shrugs:
RedHat is specifically targeted to government and enterprise. They would be aware of that.
A better example is a user I should be able to install python 3.7 and use it, even if the system libraries for the core packaging is based on python 2.x. Traditionally most users would just build their system scripts on python 2.x (because it is there), which means that if you upgrade the distro from RHEL X to RHEL Y (which brings a python 3.x) you break a user's environment. This was a constant problem when you were trying to go through the RHEL 5-6-7 upgrade paths among other things.
It hopefully will be resolving the issues of people and packaged software using weird old versions because it is there and breaking when something changes. My favourite example is having to write in ancient bash just to support MacOS which still ships bash 3 something.
In a shorter version, the interpreters are still there and buried, just not on $PATH and given to the user as a what they should use.
(This is opinion based on how I have seen people abuse systems and try to upgrade them over the years).
It takes a lot of work to keep software going, both developers and time. Wondering where it comes from. If it's free it's not getting money from users to finance that; if the user base is dwindling it also means there are few developers or other-company employees to work on it.
Perl, like many other languages, has its own bubble. I'm using Perl daily at work. I used Python for a while, but the Perl job market was just too nice to pass. I have a backlog of clients interested in Perl work longer than I can handle, and they don't mind my requirements because they have no one to replace me with.
Is that a sign of a dying language? Probably yes. But to be honest, if it's about to become the next COBOL then I'm looking at a lifetime of profitable work with little to no competition :)
BUT: > Nothing personal with Perl. Just doing stats
Perhaps a little bit of research could help your point as well. The CGI example you mentioned is broken, but is also using a module (CGI.pm) that's been bad and wrong for so long that even Perl, with its eternal love for backwards compatibility has removed it from Perl Core. That's a sign of Perl's marketing problem, yes, but it's hardly a real indication of a language that's too old to care about fixing itself.
If it weren't for the current Python hype (AI/ML and devops), I'd have more project that require Perl than Python.
And what’s the replacement for collecting params?
I’ve used CGI.pm for both of those things.
I never used CGI.pm for generating HTML...the idea of using functions for tags seemed unneccusarily dense when HTML is a string and Perl is well suited to handling strings. Later I shifted to templating modules like HTML::Template and Template::Toolkit. I assume those are long defunct, but vfb the point is that they offered better functionality than CGI.pm
For parsing params, yes, I used CGI.pm.
I have not used it but I have heard it is as lightweight as you want (in the sense that it may be huge but you only need to use the basics if that is all you need).
But it has been quite a while since I last used Perl for cgi.
http://mojolicio.us
The CGI example is straight copy/pasted from the official Perl guide, November 2018. https://www.perl.com/article/perl-and-cgi/
> Warning you probably don’t want to use CGI for modern web development, see Why Not to Use CGI.
CGI is not used to deploy web applications anymore, I am aware of that. That's a far leap from saying the module is "broken, bad and wrong".
Another commenter pointed out that there are typo in the example so it doesn't work.
I don't know any official Perl guide? This is a blog post.
The illustration image (I gather this is what confused you) is from a 1998 book...
I am curious, how do you find clients who need Perl programmers?
Contrast with Perl, which was mainly used by niche hackers (in the original, respectful sense), used in the types of products that live by the SV valley motto of "move fast and break things".
Umm, no, I think you have a very poor idea of what Perl was and is used for, and who used it. I imagine Perl is still in heavy use (if not heavy development) in the back-end of some Banks. Perl was also used to power many of the web circa 1999. Some of the big names that used it are Amazon and Craigslist. Perl was one of the main languages used on the internet pre-2000. Much has changes since then, but let's not rewrite history to completely ignore Perl's role in where we are today.
Perl lacks uniformity of syntax which is sort of a problem, but it does excel at helping to manage the mess that is real world problems.
Personally aside from getting sucked into ~ 30% devops over the last few years, I've had trouble finding decently paid work that isn't perl. Last time I got laid off I had an alternative offer within an hour.
I suspect perl will always have a place (there are a million shell scripts out there handling issues people need solved), but it'll have a place like COBOL does; useful where it already exists, but not something you learn until and unless you need to edit a perl script.
Well, you can name your arguments if you want to. You can use hashes. Or you could just get a bunch of unnamed values.
I like this flexibity. I also like that you can make the language evolve without having to add syntax (something Java is suffering from).
That's odd. The bug works on Python. Wondering how Perl does the formatting to end up with \r\n.
Either way, still puzzling there is a typo in the official example.
The solution for this puzzle is that mod_cgi will simply convert LF to CRLF silently.
(more precisely: it parses the headers the script outputs in a relaxed way and lets the server write them in a correct format later)
If you're building a message to go on the wire as part of a protocol that needs certain specific characters, and if you're trying to write portable code, then you shouldn't use "\n" (or "\r").
This is actually covered in the "perldoc perlop" documentation under the "Quote and Quote-like Operators" section (available at https://perldoc.perl.org/perlop.html#Quote-Like-Operators):
> All systems use the virtual "\n" to represent a line terminator, called a "newline". There is no such thing as an unvarying, physical newline character. It is only an illusion that the operating system, device drivers, C libraries, and Perl all conspire to preserve. Not all systems read "\r" as ASCII CR and "\n" as ASCII LF. For example, on the ancient Macs (pre-MacOS X) of yesteryear, these used to be reversed, and on systems without a line terminator, printing "\n" might emit no actual data. In general, use "\n" when you mean a "newline" for your system, but use the literal ASCII when you need an exact character. For example, most networking protocols expect and prefer a CR+LF ("\015\012" or "\cM\cJ" ) for line terminators, and although they often accept just "\012" , they seldom tolerate just "\015" . If you get in the habit of using "\n" for networking, you may be burned some day.
So, arguably it is a bug to write it that way, but not exactly a fault of the language since it is providing a facility to do something useful and also explicitly warning you against using it for something else.
One way to think of "\n" is that it's similar to localized strings. In both cases, you have a need to let the system render something differently depending on context (platform or user location/language/etc., respectively). It's helpful to have that abstracted away, but you should realize that magic is happening and that you generally shouldn't use it for machine-to-machine communication.
Perl was a joy to use. Things that would have needed dozens of bug-prone lines of C could be done in just a few characters. Regular expressions and associative arrays were first-class language features! And, with the advent of Perl 5, there was enough scope for structuring code in a modular way that it wasn’t insane to write pretty large and serious programs.
The culture was delightful too. In those days it was centred on Usenet and mailing lists, and the general attitude was freewheeling and fun. When the first user group was set up in London, where I was living by then, I signed up immediately. That’s still the most fun I’ve ever had hanging out with programmers, and Perl was the glue that bound us together.
At some point I joined the developers’ mailing list (perl5-porters), just to see what they were up to. After a while I started to contribute: bug fixes at first, and later language features. That was fun.
So, Perl has been a big part of my programming life. But I haven’t really used it in anger for about 15 years. I still write Perl one-liners on the command line for ad hoc data processing, and actually I think Perl is still the best available tool for that, although younger coders tend not to be familiar with it any more.
But as for writing real programs? The world has moved on. There are newer languages that have taken the good ideas from Perl, but without so many confusing idiosyncrasies.
Perl 6 is another story, one that I didn’t have much part in. It’s a fun bundle of ideas, and maybe some of those ideas will spread and be useful elsewhere, but I doubt it will ever catch on itself.
I’ll always love Perl, but I doubt I’ll ever write another serious program in it – except maybe out of nostalgia.
Very poor stats if you're extrapolating the time a market participant will be reduced to zero by looking at relative market position without also examining absolute usage.
That is, it's possible for something to have less relative market position but be increasing or static in total usage if the total market is increasing fast enough. That doesn't indicate something is dying, but it looks the same in graphs, and extrapolating from those lines won't show you what you think it is.
Is Perl in that situation? Probably not that much (but somewhat, I would argue), but if you're going to make a case on statistics, don't do a crappy job of it...
I’ve seen mind-curdlingly horrible Perl of several varieties (novice, mad genius, and the biggest ugliest balls of mud you’ve ever seen), yet nothing has yet touched even the hem of the horrors I presented over-architected Java ravioli with acute patternitis.
It says in the source article "you probably don’t want to use CGI for modern web development", then explains all the reasons why not, pointing you to modern frameworks such as Catalyst, Mojolicious and Dancer.
Not saying Perl doesn't have challenges with its popularity, but this isn't a very good case as to why it's dying.
Basic CGI script to show all GET request parameters. If you were writing an HTTP API, you would probably do something very similar although not running over CGI.
Surely a more constructive comparison might be looking at a 1 page app in Mojolicious vs Flask, Express, etc?
I don't even get statements like this. And what does 'heard about it mean' anyway.
Interesting I just pulled up another quick and dirty test compliments of HN Search (Algolia):
Last Year Story Titles:
Perl: 301 Python: 3,360 Java: 3,931 Ruby: 687 Ruby on Rails: 105 HTML: 214,423 Bitcoin: 1,398 Blockchain: 1,622
Adding Bitcoin and Blockchain I was just curious. But imagine if I wanted to prove popularity by using 'last year in Hacker News' in titles. It would appear that Python was 'more popular' than Bitcoin or Blockchain.
No question it's less popular than it was years ago for numerous reasons. Not sure the methodology used (google trends) tells the complete picture.
> Python – 1989
> Ruby on Rails – 2005
Ruby itself is 1995. In 2005 when Rails was coming out Perl had it's peak according to Tiobe:
> Highest Position (since 2001): #3 in May 2005[1]
> That makes one wonder about who else is still using Perl? if any? Can’t remember the last time I’ve heard about it.
Duckduckgo? [2]
Sure, Perl is loosing popularity but I don't think it's anywhere near dead or extinct.
[1] - https://tiobe.com/tiobe-index/perl/
[2] - https://github.com/duckduckgo?language=perl
(I use them throughout my code, except for modules that should stay compatible with very old versions of Perl.)
But folklore is a thing. Many people learned Perl before named parameters, and to be fair they took about 20 years to arrive (and are still called "experimental"!). People don't like to change now.
I think most people writing new Perl code still use the no-named-arguments idiom, just because it's old and familiar. Which makes code look more arcane than it needs to, to outsiders, unfortunately.
In fact I recently snuck some perl code into production at my company a month or so ago: we needed an android app to post data to a backend where it could later be analyzed. Super simple. I wanted to get it out the door as fast as possible and due to the fact that it will be retired before the end of this year, I choose to write the backend in perl using MongoDB and Mojolicious. Then I saw that MongoDB is retiring their driver for perl[1]. I still went forward, but it was yet another reminder of the state the language is in.
It saddens me that perl does not get more love. It is a fantastic language but I can not justify teaching others it, or encouraging them to learn about it.
[1]: https://www.mongodb.com/blog/post/the-mongodb-perl-driver-is...