20 ms·

The reports of Perl’s death have been greatly exaggerated

105 points by zdw 5y ago

pugworthy 5y ago
It's not dead until I retire my canvas bag from the first O'Reilly Perl Conference.
orf 5y ago
https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo Look at the first code snippet. Complete and utter nonsense. Or this other golden child of “advanced object systems”: https://github.com/moose/Moose https://github.com/moose/Moose Dead. As a doorknob. Sorry. Languages come and go. Perl has gone.
- nrdvana 5y ago
  And yet, the “nonsense” you see is the object paradigm I love the best out of any language I’ve ever used. It’s what keeps me on perl instead of moving on to other more trendy (and restricted) languages.
  - orf 5y ago
    You can do everything on that page in Python or Ruby without issue.
    - nrdvana 5y ago
      I didn't say you couldn't, just that the 'nonsense' is actually quite nice to use in practice. Lets play Rosetta Code for lazy attributes: package Something; use Moo; has hostname => ( is => 'lazy' ); sub _build_hostname { chomp(my $x= `hostname -f`); $x } How would those look in Python or Ruby? Meanwhile there are many things not on that page which Perl can do and Python and Ruby can't. (most related to taboo runtime changes of global state which are not recommended, but come in very handy when debugging)
      - orf 5y ago
        > How would those look in Python or Ruby? class Something: @cached_property def hostname(self): return socket.gethostname() I guess, kind of hard to tell what your code does because it is honestly indirect nonsense where you need to know details about some specific library that implements some specific form of objects written in a language that is not exactly well regarded for it's legibility. Meanwhile the code above is clearly readable by anyone with even a modicum of programming experience. There's also nothing on that page that I can see which Ruby and Python couldn't do. Both are exceptionally good at taboo runtime changes of global state.
        nrdvana 5y ago
        Interesting, I hadn't seen @cached_property before. I was expecting you to have to muck around with __getattr__. The lazy attribute in Perl is simply one whose constructed value is deferred until the first time it is used. For an example of taboo runtime changes, suppose you have one module which operates on a tree of data, like converting to JSON, and another type of object within that tree which does not have a built-in serialization to JSON, like DateTime. (there is really no way to universally serialize a DateTime to JSON because JSON only supports strings arrays and objects, and representation of dates will be application-specific). Perl lets you temporarily inject a method into a class for the duration of a scope, in this case the TO_JSON method which the JSON module looks for: sub export_as_json($data) { local *DateTime::TO_JSON= sub($date) { $date->ymd }; JSON->new->convert_blessed->encode($data); } After that scope, the DateTime package is restored to normal, without a TO_JSON method. How would Python solve this problem?
        orf 5y ago
        So firstly, it's not up to an object to know how it should be serialized to JSON. It's up to the serializer, and that can be trivially done with the `default` argument: def encode(obj): if isinstance(obj, datetime.datetime): return obj.isoformat() raise ValueError() json.dumps(..., default=encode) In Python your code above can usually be done with: date = datetime.date.today() date.foo = lambda self: print("hello!") date.foo() And this will work on any object that's not defined in C (which unfortunately datetime objects are): class Omg: pass Omg.foo = 123 print(Omg.foo) If you wanted that reverted after a block is finished, you'd use a with statement: with patch(date, "foo", some_value): date.foo() There is rarely a need for this outside of tests though. More generally, you can modify any non-c Python object in any way you want. Nothing is private or protected. If you're thinking that Perl is special because it has reflection and a dynamic object model, or lazy properties, you've been asleep for quite a while. These have been table stakes for a very long time.
davidw 5y ago
If you have to write forceful "It's not dead! Really!" blog posts, it kind of gives away the Weekend at Bernie's game. Snark aside, to try and add something more useful, having seen languages rise and fall, it seems that "not growing" or "gradually losing ground" are kind of what people label as "dead". If lots of people aren't regularly starting new projects with it... it's not healthy. I wrote something similar about Tcl years ago: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
- newaccount2021 5y ago
  I love perl and simultaneously totally at-peace with it being "dead"...but it really isn't. Packages I care about are updated regularly. The core release is deployed regularly. There are numerous meaningful improvements discussed on p5p. Fastmail, my email provider, runs on perl. You can get perl jobs in 2021. The community is smaller now but more dedicated - not growing, but not dead either. In any case, none of the moderately popular languages will die anytime soon...between the platforms that still run on them, and the geezers who have the time in retirement to volunteer, tools will survive
  - davidw 5y ago
    > none of the moderately popular languages will die anytime soon Correct. As long as people are using stuff in production, the high costs of switching ensure that some maintenance will keep happening. That's why we still have things like COBOL, even though I don't think much of anyone is all that enthusiastic about it.
- forgotpwd16 5y ago
  >If you have to write forceful "It's not dead! Really!" blog posts How is this different from modern languages making similar posts about how they're very active?
  - justinator 5y ago
    Saying, "we're very active" is a different framing than saying, "Reports of my death have been greatly exaggerated".
1024core 5y ago
I believe Numpy/Scipy really put some wind behind Python's sails. Are there equivalents for Perl? Perl was my first love, but I rarely reach for it now, since I spend most of my time data munging and doing Tensorflow.
- forgotpwd16 5y ago
  PDL (http://pdl.perl.org http://pdl.perl.org). And it's pretty old too, having started in late 90s.
- cjm42 5y ago
  I believe https://metacpan.org/pod/PDL https://metacpan.org/pod/PDL would be the closest Perl equivalent, but it's not my field and I haven't used it.
- deleted 5y ago
  [deleted]
- edgyquant 5y ago
  Numpy/Scipi/Pandas/tensorflow etc all did for scientific/analytics but web frameworks also helped. Today what makes python so easy to use is the fact that there is multiple modules for everything.
  - mywittyname 5y ago
    Yet, deployment/versioning of python remains a shit show. Just the other day, I ran into an issue with the setproctitle package where certain implementations exposed a method via CPython while others didn't. So not only did it matter which version of python you used, but it mattered how it was compiled. The kicker is, the official OSX build from python.org doesn't work, you have to use a version that comes with OSX. Only Python would have such a ridiculous problem in 2021. I love Python, but it's best left in the data science space. Maybe the odd micro-service in Flask.
jerf 5y ago
The real problem with these kinds of posts is the equivocation in the word "dead". People wanting to defend languages (also APL lately) want to implicitly use a definition something like "0 people are using it and no work is being done in it", but by that standard you can't ever declare anything dead. That doesn't make the definition "wrong" but it does make it not useful. The purpose of a definition is to split the relevant set of possibly values into at least two non-empty sets. Other people are looking at the first and second derivatives of how many people are using it, how popular it is now compared to its height (in the programming language world it's already a problem if your "height" of usage isn't right now), and the likelihood of it ever coming back. From that point of view, Perl 5 is, if not dead, certainly very close. To me, most tellingly, Perl 5 has no plausible path that I've heard for acquiring some unique value proposition that can give it a new lease on life. As I said in https://news.ycombinator.com/item?id=26567151 https://news.ycombinator.com/item?id=26567151 , in a lot of ways Perl's biggest problem right now is that it won. It convinced people that its way was good, and as a result, Perl's previous value proposition has been incorporated wide and far in other languages. The only time I pick up Perl now is when I have the need for a seriously heavy-duty string munging task that fits into about 200 lines, and I get huge wins from the RE syntax in Perl. And by time-of-use, Perl is probably my "best" language, the one I've used for more clock time than any other. Even so, that's where I am in 2021. I would encourage the community to either decide that it's OK just continuing on as it is, or decide that it wants to try to find that new unique value proposition that will give it some sort of unique value in 2023 or 2024. But there isn't an option where Perl continues along as it is and it experiences some sort of burst in growth. You have to pick one, you can't get the advantages of both.
- newaccount2021 5y ago
  if people want to try to quantify "dead", a good place to look at is activity on cpan https://metacpan.org/recent https://metacpan.org/recent many packages I rely on have weekly updates
- deleted 5y ago
  [deleted]
- justinator 5y ago
bachmeier 5y ago
What I wish would die is discussions of the death of languages. It's as useful as classifying people as good and bad athletes. Everyone is better or worse at some sports, and the threshold for switching from good to bad is purely arbitrary. It's better to have discussions with substance. "Perl job advertisements are down 34% in the last five years" might be useful. "Perl lacks libraries to do [task]" might be useful. "Perl is dying" isn't.
oblib 5y ago
I rewrote all my Perl app code in JS to run entirely on the client side years ago but Perl is still my go to server side tool. For example, I used to use HTML:Template, now I use Mustache.js. I'm quite sure I could do most anything I do with Perl with Python instead but since that would be pretty much the only thing I'd use Python for I'd spend more time learning how to do it than is necessary. I still use CGI.pm for a lot of what I do on the server side, which is not very much anymore. But for what I do use it for it's very good at and I've never had a problem with it.
htrp 5y ago
I think the business life cycle is also a useful analogy for languages at some point no new software should be developed in a given language and you should just be maintaining existing code bases corresponding to managed .decline
pram 5y ago
The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness. Starting today I'd obviously have learned JS or Go or Java or Rust or Python instead. Perl in 2021 probably seems like some curious antique like AWK, if they've even heard of it. That is the real problem I think. There is just no good reason to use it, and thus learn it. It doesn't do anything better than the alternatives. It's not "dead" but there is very little new blood entering the scene. It's a retirement home.
- tyingq 5y ago
  I imagine the old "Command Line Tools can be 235x faster than your Hadoop Cluster" story still applies. That is, there's probably a fair amount of data processing that could be done well with Perl (or awk, etc).
- bluedino 5y ago
  >> The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness. It was _the_ choice to use to write web pages in at one point. I remember installing RedHat Linux, writing a support 'forum' message board thing in Perl, then chucking it away as everyone was starting to use ColdFusion, PHP and .NET
  - cyberge99 5y ago
    CGI was the way back then (still is in a way).
- oneweekwonder 5y ago
  > Perl in 2021 probably seems like some curious antique like AWK Sure you can call awk an antique tool being 44 years old, but its available on almost all unix-like systems even on router running busybox or bare minimum containers using alphine. So its definitely a personal nitpick of mine calling a very relevant tool an antique.
  - shagie 5y ago
    Somewhere, I've got a book for programming awk. It's got some really neat things in there that are non-trivial awk scripts from yesteryear. I could see that being useful in the 70s or 80s... but not today. No-one writes awk more than a line or two today that's nestled in some ci script that is never looked at again. Yes, the tool is ubiquitous - its everywhere. It also happens to be part of the standard of what is on a machine which keeps it being used for those two liners. However, people aren't writing applications in awk anymore. Similarly, perl is going to go the same way. It's going to be useful for those 10-20 line data transformations that are in some data pipeline for munging data. But its not something that's continuing to grow and find its way as a first choice. Writing a new application in awk is something that people do for the exercise - much like going and doing your own primitive photography with a cyanotype. It's done as a "yes, I understand it enough to do this complex thing." Perl is a bit further back... it's developing your own film. There are still some people who do that as a matter of their business - but its not a first choice anymore. Cyanotypes and doing your own darkroom work are things of antiques in today's age. They're not gone - but doing things in them is more like going to the pioneer town and seeing how it used to be done rather than a practical choice for today.
streamofdigits 5y ago
Billion dollar companies have been built on perl[0]. So let us not seek to fix the blame for the past, let us accept our own responsibility for the future. Seriously though, how large a collection of programming language ecosystems does the world want or need? How many equivalent stacks, all solving the same problems with more or less the same patterns and concepts? Just a thought: Open source communities could benefit from less dispersion of energy and talent, less endless re-invention of the wheel, less endless "not-invented here syndrome"... [0] https://www.slideshare.net/cmnunes/bookingcom-perl https://www.slideshare.net/cmnunes/bookingcom-perl
- dreyfan 5y ago
  There’s far more venture capital than innovative ideas and the business problems are rarely hard to solve. Engineers get bored so we have a constant flow of new languages, frameworks, and lately, an overwhelming focus on tooling and infrastructure. At the end of the day, most companies are just generating dynamic HTML after performing some rudimentary CRUD database operations. It’s disappointing so much time and money is spent only to arrive at the same place that /cgi-bin/ and a perl script solved over two decades ago.
- mywittyname 5y ago
  >how large a collection of programming language ecosystems does the world want or need? There are many problem domains that can be solved by computers, and having a language specific or well suited to that niche can be a productivity boon. As long as humans continue to discover new problem domains in computing, they will continue to develop new programming languages to work in them more efficiently (and existing languages will expand to try and fill that niche).
  - streamofdigits 5y ago
    yes, I am not arguing for a single language. But many of the domains you mention are actually intrinsically similar once you map them to the underlying information flows. This explains for example the extreme ubiquity and longevity of things like relational databases and SQL. There are several genuine and orthogonal domain "dimensions", e.g real time systems or parallel processing etc, but I would say that is a handful, not the multiple dozens even hundreds of idioms we use to program digital devices...
xdfgh1112 5y ago
Weird timing considering the community is actually dying right now - lots of talented people have left recently and many of my pro-Perl friends have stopped using for good.
- doomvox 5y ago
  Don't know exactly who you mean, but while sawyer x has stepped down recently, the dev team seems to be in good shape-- they've adopted the steering committee idea, and are using an informal RFC process to make decisions about new features.
bloak 5y ago
I use Perl all the time for short programs, up to a few hundred lines. The main advantages of Perl are that it's already installed on all the systems I use and the language itself is not changing: Perl scripts I wrote 20 years ago still work, and I have a vague hope that Perl scripts I write today will still work in 20 years' time. Maybe Python is now stable enough for me to consider it as an alternative to Perl but I've bad experiences trying to run Python scripts from 20 years ago. In any case, Python is less concise for the sort of programs I write, and although Perl has a reputation for being unreadable it really depends on who's writing it. I write in a subset of Perl, with "use strict", that I find to be readable. I find Perl stops being convenient at about the point where you need complex data structures and modules.
Thaxll 5y ago
Perl is pretty much dead, actually I've never seen or touch or heard new project being built in Perl for the last 10 years. Python took over.
- stevekemp 5y ago
  Perl is used in the background for lots of glue, and integrations. But I don't think it was python that took over from Perl. When I think of the kinda web-applications I was writing they got replaced by Rails, PHP, and similar.
CodeWriter23 5y ago
I’ve coded in Perl since the late 90’s up until about 3 years ago. Thought Dancer and Dancer2 were awesome web frameworks. Especially loved making my own app-specific DSL. Then I took a consulting gig and the framework server side was Laravel. I switched and never looked back. I’m even porting one of my Dancer2 backends to Laravel. My main reasons: 1. Laravel has so much momentum, the tooling is so superior to Dancer2 that the Dancer2 crew will never catch up. The schema migration management alone is a killer app that will drive switching. And tons more. 2. In patio11’s post about selling Bingo Card Creator, he indicated implementation language is a key consideration for a buyer. They want to be able to draw from a larger and possibly less expensive talent pool for maintaining and extending the software. PHP wins on both of those metrics. 3. I’ve reached the point in my life where I want to do stuff WITH as opposed to do stuff TO my applications. Size and cost of the Talent pool is relevant in this way to me for the simple reason I know there aren’t enough hours in the day to do it solo. I always wanted Perl to make it back into the mainstream. It will never die. But to me at this point, Perl is as impractical as some of my crazy ex-girlfriends. I bid it the same affectionate farewell.
mmaunder 5y ago
While the authors accusation audit is impressive, I can assure you, as a CPAN contributor and someone who has launched some very successful Perl web apps, that Perl is in fact, completely and utterly dead. It died well over a decade ago when all focus moved to Perl 6 which didn’t emerge until recently. Everyone moved on except a hardcore group of advocates. They aren’t coming back. If a new language and community emerges that happens to have the same name, I’ll certainly take a look. That hasn’t happened yet. And it’s a damn shame because the mod_perl list and community had some killer talent in it that was creating the most innovative and heigh performance web applications out there. I created WorkZoo in Perl which was a very high performance job meta search engine and was one of Time Magazines top 50 sites in 2005. What happened to Perl is a damn shame. Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.
- kamaal 5y ago
  >>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled. Who uses php these days? I haven't heard any one start a new php project in years. Ruby seems to have gone the same way. Python seems to have won the backend game, which actually makes sense as Python today is bloated like how Perl was once. And these days it feels like Perl with tab indentation. No wonder it fanatic following these days. Frontend game is now owned by Node, ReactJS, JS etc. Who uses php to do anything? In fact I don't know of a single college kid I've hired who has even looked at php let alone used it.
  - nrdvana 5y ago
    WordPress, Drupal, Magento, Joomla, OpenCart and lots of other open source community CMS and online web-store type things are built on it. Sadly it will never die because it has Facebook pouring money into it.
  - mgkimsal 5y ago
    Why is "college kid skills" relevant for anything? Do you make tech and business decisions based on what your incoming jr people want to do? Many people in my circles use PHP for ... lots of stuff. I just got back from a PHP conference, and saw hundreds of people there are using it. "Python seems to have won the backend game" - I'm really curious where you get that impression from. I can't imagine it's relating to publicly available web servers. That's not a total view of everything, of course, but... absent other numbers/studies/reports, it's really hard to draw any conclusions that aren't just based on personal experience.
netcraft 5y ago
What I would like to see in posts like this is a description of the kinds of programs the author thinks are great candidates for this language over others, maybe with an acknowledgement of the other options and a comparison of why (in this case) Perl might be a better choice. I see a lot of the things listed that they think are strengths, but many of them are shared by other languages that don't have the negatives (even if a lot of those negatives are just perceived) - so why should I choose Perl in 2021? I have professionally written a few languages in my life that the zeitgeist would consider "dead" - what I always see in those communities is a lot of people crying that they aren't dead like something out of monty python - and that its "actually a great language", but no real pitch about _how_ that would apply to the prospective people who might pick it up. These conversations always come across as delusional, fan-boyish, and the opinions of people who feel pot committed to the language they've spent so much time in and are not willing or able to pivot, begging people not to think that they chose poorly. I truly don't know if this applies to Perl, I certainly have opinions long held and maybe things have changed over the years, but in a world with so many great options today, to make a dent you have to paint a picture for people to convince them to give it a shot.
debacle 5y ago
I still love Perl. If I had the opportunity to work on an existing Perl project, I would relish the nostalgia. I would never, ever use Perl for a greenfield project unless there was a library that was absolutely crucial to the development, for many reasons. Perl 6 was so disastrous to the ecosystem that it effectively killed the language. If 20% of the effort that went into Perl 6 had gone into keeping the language fresh, I think Perl would still be part of the conversation today.
bloblaw 5y ago
Perl is simply a tool. I still use it all the time for small scripts and automation. I know Python, Go, C#, and a bunch more....but I reach for Perl when the task calls for processing lots of text, or quick automation. Others might reach for Python or Ruby or Go. For me it's a better bash script, a better grep, a better awk, a better sed. That's what Perl was designed to be, and I don't think any other scripting language matches it for that purpose. It is not a tool to build desktop applications or the first choice for web applications in 2021. But it is still extremely useful for its niche...processing data/logs/text, or system administration tasks. It really shines there and that's how I use it. It's another tool in my toolbox, and learning Perl has made me more productive and I still reach for it today.
- brtastic 5y ago
  The tool analogy is flawed. Languages that move fast and break backward compatibility are tools, but organic. If you leave them in your toolbox for too long they start to rot. This does not apply to those languages that do not get updated (bash?) and that does not break backwards compatibility (perl? but without CPAN modules). I know that my PHP tool has rotted even though I was actively using it. It moves too fast and the frameworks I was using are no longer any popular - should've learned symfony instead of yii, now laravel is taking over
coldtea 5y ago
Nope, they're accurate. But I guess hope is eternal.
moedersmooiste 5y ago
Booking.com is the only big website I know that still uses Perl...
- doomvox 5y ago
  Adultfriendfinder, cams...
- vajrabum 5y ago
  Craigslist.com also still uses perl.
  - jzawodn 5y ago
    s/\.com/.org/
Animats 5y ago
There should be a convention where the APL people, the LISP people, the Perl people, and the Pascal people get together and talk about the good old days.
- int_19h 5y ago
  I miss Algol 68. ~ (Seriously, though - in retrospect, it feels like most of the complexity that the language was criticized for is standard fare in PLs of today, often in the same shape.)
- manbart 5y ago
  Include Tcl and I’m there!
- justin66 5y ago
  I'm a little freaked out by the prospect of any crowd where the Perl people are the youngest ones.
chefandy 5y ago
The only reasons I could think to use perl over Python are regex execution speed and 'maybe' infeasibility of accessing PyPI so you'd need more built-ins, but still have plenty of disk space... though I haven't done any feature parity comparisons there. Am I missing anything? I liked Perl back in the day and used it a lot but even my old sweet-jesus-what-was-I-thinking Python code is a LOT more readable than my cleanest old Perl code. I'd be curious to hear from folks who've also been deep in Python and Perl but stuck with Perl rather than Python— different use cases? Coding styles?
- extortionist 5y ago
  My job is split between maintaining a giant legacy perl codebase and doing new dev work in python. I vastly prefer python overall, but perl's still the best when you need quick one-off scripts to tear through log files or do some quick regex subs on a bunch of files. I don't think python has an equivalent of 'perl -p -i.bak -e 's/foo/bar/g' *', for example (which will do in-place regex substitutions on whichever files are passed in, additionally copying the original files to 'original.ext.bak'). The regex syntax is also bit more streamlined in perl, so I find it quicker and easier to throw together a script that's just doing regex stuff in it. A simple example: >> $string =~ m/(pattern)/i; >> my $match_text = $1 || ''; >> $string =~ s/pattern//gi; >> import re >> match_obj = re.find(r'(pattern)', string, flags=re.I) >> match_text = '' >> if match_obj is not None: >> match_text = match.group(1) >> string = re.sub(r'pattern', '', string, flags=re.I) Of course, the same magic that makes perl great for those one-off kinds of scripts makes it less than ideal for complex or long-living scripts that need to be maintained by multiple people, in my opinion.
  - chefandy 5y ago
    No doubt: the regex syntax in Perl is most efficient. I can envision using Perl more if I ever got back into a command line focused text manipulation workflow. I tend to use lighter-weight tools for things like your one-liner— I believe `sed -i '.bak' "s/foo/bar/" *` is equivalent, but I disagree with the neckbeard purists who say you should always use the lightest-weight tool possible. If you're using Perl anyway and Perl can get the job done with the smallest cognitive load, that's the correct tool.
cafard 5y ago
I don't often write Perl these days, but I did this week. I was amused to find that I was using "def" rather than "sub" to declare functions.
chipuni 5y ago
A good measurement of whether a language is "dead" or not is the TIOBE index: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Is Perl dead? No, it's still among the top-20 programming languages. Is Perl dying? Yes; it dropped 8 places among the top-20 programming languages.
- Hjfrf 5y ago
  The list is based on search engine hits for "x programming". That's probably fine for comparing c to c++ or perl. Searches for "scripting" or "coding" instead are not counted, which probably explains shell scripting below languages 20x less popular if you search by the name alone. Powershell at ~40, bash not even top 50. You'd assume both are dead from this list.
- justinator 5y ago
  Oh so Perl is owned by Schrödinger?
giantrobot 5y ago
Perl isn't dead but its usage is not growing and I don't see any reason it will ever grow again. Unless you're an old school Perl hacker there's little reason to start a green field project with it today. I say that as someone that has written a lot of Perl over the years. It turned out to be an awesome language for CGI apps in the early days of the web (the reason I learned it). It was also a better system administration/automation language than some bash/awk/sed/grep amalgamation. For me at least it fell down once you got over a few hundred lines. The TMTOWTDOI led to your own (or at least my) code being internally inconsistent and the lure of its shorthand meant coming back to old code took some effort to understand. I moved from Perl to Python and it helped immensely with both those problems. Once I grokked Python's regex I could do everything in Python I used to do in Perl with the same speed but half the effort. I don't see any attraction of going back to Perl. It was a nice tool for a time but now there's better tools (IMO). So once old deployments of Perl apps/tools are replaced I really don't think they're going to be replaced with Perl.
G3rn0ti 5y ago
Eventually every technology will age and die after some time. Today, you may be proud of your intimate knowledge of Python, Golang, C++ or even JavaScript. But in 20 years from now people will have gone on and you might be left behind. So to all young and smug whippersnappers here: Memento mori!
- justinator 5y ago
  What you need to find is a willing host to totally monopolize. JavaScript just isn't going away from the browser in my lifetime and JavaScript started out as a completely hobbled language that still has major warts. Perl doesn't have that. Reads in strings, do stuff, outputs strings? Welcome to Unix!
sethammons 5y ago
We managed a several thousands node cluster of perl services. We took several years, but we recently finished migrated all of this off from stateful Perl to stateless Go all the while growing rps volume 40% yoy and migrating datastores as we scaled those too, continually improving stability and availability, adding features, and scaling the org from a few hundred people to a few thousand. We are now 100% off perl for our critical path. Perl is not on my resume :)
- arunix 5y ago
  What does stateless Go mean?
  - sethammons 5y ago
    Stateful means state is stored in memory or on disk by the processing service. Stateless means that state is stored distributed to multiple nodes and can be recreated or that there is a design such that no state is needed. In the first case, a node dies and information is lost, in the latter, no information is lost. This allows for greater scale by often saving resources per request and increasing resilience. A concrete and simple example: an api request comes in and you call n dependent services before responding. If any of those calls fail, the entire response 500s, if ok, respond 200. Instead, make this a job with a 202 response with an id returned and use a distributed queue and workers to async process the request and allow the job results to be queried by job id. Now any node failures are invisible to the client.
0xbadcafebee 5y ago
I still use Perl all the time for random tasks. It is exceedingly fast and simple to create very powerful programs using stable libraries, and all the legacy code still works. It's the most handy general purpose scripting language, period. And you can run it anywhere. I don't use it for "portable" things, which is funny because it's more portable than any language I can think of. I write things in Python if anyone other than me has to support it or run it, and Bash if it's just going to be embedded in a system where I don't want to make Perl a dependency. But to do something powerful and fast just for myself? It's Perl, baby.
MarkusWandel 5y ago
On my Linux system I could, if I wanted to, write programs in (the subset of bash that is) Bourne shell, awk, plain old 1970s vintage C, implement text filters in sed... all these are antique things that don't need a vibrant user community. They just need to work well enough to support existing stuff written in them, and for an occasional quickie script by old farts who know how to use them. Why should Perl be any different? It'll be decades before a practical system won't have a Perl 5 compatible /bin/perl on it. So if I know Perl well enough that I can hack something up in 5 minutes, and Perl is there and works, how is it alive or dead? It just is. And that suits me just fine.
- mongol 5y ago
  Good point. The alive / dead metaphor is not so useful to descibe the language itself. Perhaps it is the community that should be described as alive or dead. The language itself is just a tool. It never was alive, but as long as it works, it is useful for those that choose to use it. Just like a hammer can be useful long after the toolsmith that made it died.
alexeiz 5y ago
I haven't used Perl in ages. Seeing all these new features in Perl 5, I want to use it again. I've looked at Raku and didn't like it. I think it went astray and it doesn't fit the spirit of Perl (being practical).
uxp100 5y ago
What's the replacement for Perl based Verilog metaprogramming in the Intel (I think) style? I'm being a little cheeky, but that is a use-case for perl at a few of the places that make the processors that the web-frameworks that no longer use perl run on. I no longer work at a semiconductor company, maybe they're moving away from that, but I'm not sure what would replace the in-line perl in verilog files that use perl as a pre-processor.
rektide 5y ago
I would love to see more innovation in scripting languages. Nothing (I've seen) comes as close to perl for swizzling together a decent, capable, handy programming language with a variety of system binaries & other shell scripts. There's a couple efforts like shell.js[1] or the far simpler/more-contemporary zx[2] to give shell-scripting like ease to js. zx's core is just at tagged template string for running system() calls, basically, ex: $`echo 2+2`. I still find the experience pretty sub-par compared to how shell & scripting first languages like Perl are. Perl is just super powerful, keeping a foot in a more user-land like environment, versus the totalizing experience of libraries. Why do you need to pick a http client library to use when everyone is already quite intimate with curl & it's already on the system? Somehow coding keeps taking more turf, but I feel like Perl's scripting was extremely glorious & largely un-reproduced. Perl is still some of the best "glue" the planet has seen. And glue, as we've read a couple times on HN[3][4], & which I agree with, is really important, dominates what we build. To the topic itself, as a Debian user, I appreciate Perl, but I wish it weren't on my OS taking up ~20MB of space & being more & more offbeat, but it's probably never going away. Not sure why it irks me that my computers will all need that ~20MB of Perl + Debian perl libraries. And it is pretty cool how debuggable & visible the Debian tools often are, because they're scripts, not compiled programs, by & large. But there's a lot of operators to lookup & a lot of implicit variables to remember in Perl programs, and it's a reminder how offbeat Perl is, every time I poke my head in. [1] https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs [2] https://github.com/google/zx https://github.com/google/zx [3] https://news.ycombinator.com/item?id=27486706 https://news.ycombinator.com/item?id=27486706 https://blog.metaobject.com/2021/06/glue-dark-matter-of-software.html https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft... [4] https://news.ycombinator.com/item?id=27880183 https://news.ycombinator.com/item?id=27880183 https://www.oreilly.com/radar/thinking-about-glue/ https://www.oreilly.com/radar/thinking-about-glue/

105 points by zdw 5y ago

It's not dead until I retire my canvas bag from the first O'Reilly Perl Conference.

orf 5y ago

https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo Look at the first code snippet. Complete and utter nonsense. Or this other golden child of “advanced object systems”: https://github.com/moose/Moose https://github.com/moose/Moose Dead. As a doorknob. Sorry. Languages come and go. Perl has gone.

nrdvana 5y ago
And yet, the “nonsense” you see is the object paradigm I love the best out of any language I’ve ever used. It’s what keeps me on perl instead of moving on to other more trendy (and restricted) languages.
- orf 5y ago
  You can do everything on that page in Python or Ruby without issue.
  - nrdvana 5y ago
    I didn't say you couldn't, just that the 'nonsense' is actually quite nice to use in practice. Lets play Rosetta Code for lazy attributes: package Something; use Moo; has hostname => ( is => 'lazy' ); sub _build_hostname { chomp(my $x= `hostname -f`); $x } How would those look in Python or Ruby? Meanwhile there are many things not on that page which Perl can do and Python and Ruby can't. (most related to taboo runtime changes of global state which are not recommended, but come in very handy when debugging)
    - orf 5y ago
      > How would those look in Python or Ruby? class Something: @cached_property def hostname(self): return socket.gethostname() I guess, kind of hard to tell what your code does because it is honestly indirect nonsense where you need to know details about some specific library that implements some specific form of objects written in a language that is not exactly well regarded for it's legibility. Meanwhile the code above is clearly readable by anyone with even a modicum of programming experience. There's also nothing on that page that I can see which Ruby and Python couldn't do. Both are exceptionally good at taboo runtime changes of global state.
      - nrdvana 5y ago
        Interesting, I hadn't seen @cached_property before. I was expecting you to have to muck around with __getattr__. The lazy attribute in Perl is simply one whose constructed value is deferred until the first time it is used. For an example of taboo runtime changes, suppose you have one module which operates on a tree of data, like converting to JSON, and another type of object within that tree which does not have a built-in serialization to JSON, like DateTime. (there is really no way to universally serialize a DateTime to JSON because JSON only supports strings arrays and objects, and representation of dates will be application-specific). Perl lets you temporarily inject a method into a class for the duration of a scope, in this case the TO_JSON method which the JSON module looks for: sub export_as_json($data) { local *DateTime::TO_JSON= sub($date) { $date->ymd }; JSON->new->convert_blessed->encode($data); } After that scope, the DateTime package is restored to normal, without a TO_JSON method. How would Python solve this problem?
        orf 5y ago
        So firstly, it's not up to an object to know how it should be serialized to JSON. It's up to the serializer, and that can be trivially done with the `default` argument: def encode(obj): if isinstance(obj, datetime.datetime): return obj.isoformat() raise ValueError() json.dumps(..., default=encode) In Python your code above can usually be done with: date = datetime.date.today() date.foo = lambda self: print("hello!") date.foo() And this will work on any object that's not defined in C (which unfortunately datetime objects are): class Omg: pass Omg.foo = 123 print(Omg.foo) If you wanted that reverted after a block is finished, you'd use a with statement: with patch(date, "foo", some_value): date.foo() There is rarely a need for this outside of tests though. More generally, you can modify any non-c Python object in any way you want. Nothing is private or protected. If you're thinking that Perl is special because it has reflection and a dynamic object model, or lazy properties, you've been asleep for quite a while. These have been table stakes for a very long time.

davidw 5y ago

If you have to write forceful "It's not dead! Really!" blog posts, it kind of gives away the Weekend at Bernie's game. Snark aside, to try and add something more useful, having seen languages rise and fall, it seems that "not growing" or "gradually losing ground" are kind of what people label as "dead". If lots of people aren't regularly starting new projects with it... it's not healthy. I wrote something similar about Tcl years ago: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...

newaccount2021 5y ago
I love perl and simultaneously totally at-peace with it being "dead"...but it really isn't. Packages I care about are updated regularly. The core release is deployed regularly. There are numerous meaningful improvements discussed on p5p. Fastmail, my email provider, runs on perl. You can get perl jobs in 2021. The community is smaller now but more dedicated - not growing, but not dead either. In any case, none of the moderately popular languages will die anytime soon...between the platforms that still run on them, and the geezers who have the time in retirement to volunteer, tools will survive
- davidw 5y ago
  > none of the moderately popular languages will die anytime soon Correct. As long as people are using stuff in production, the high costs of switching ensure that some maintenance will keep happening. That's why we still have things like COBOL, even though I don't think much of anyone is all that enthusiastic about it.
forgotpwd16 5y ago
>If you have to write forceful "It's not dead! Really!" blog posts How is this different from modern languages making similar posts about how they're very active?
- justinator 5y ago
  Saying, "we're very active" is a different framing than saying, "Reports of my death have been greatly exaggerated".

1024core 5y ago

I believe Numpy/Scipy really put some wind behind Python's sails. Are there equivalents for Perl? Perl was my first love, but I rarely reach for it now, since I spend most of my time data munging and doing Tensorflow.

forgotpwd16 5y ago
PDL (http://pdl.perl.org http://pdl.perl.org). And it's pretty old too, having started in late 90s.
cjm42 5y ago
I believe https://metacpan.org/pod/PDL https://metacpan.org/pod/PDL would be the closest Perl equivalent, but it's not my field and I haven't used it.
deleted 5y ago
[deleted]
edgyquant 5y ago
Numpy/Scipi/Pandas/tensorflow etc all did for scientific/analytics but web frameworks also helped. Today what makes python so easy to use is the fact that there is multiple modules for everything.
- mywittyname 5y ago
  Yet, deployment/versioning of python remains a shit show. Just the other day, I ran into an issue with the setproctitle package where certain implementations exposed a method via CPython while others didn't. So not only did it matter which version of python you used, but it mattered how it was compiled. The kicker is, the official OSX build from python.org doesn't work, you have to use a version that comes with OSX. Only Python would have such a ridiculous problem in 2021. I love Python, but it's best left in the data science space. Maybe the odd micro-service in Flask.

jerf 5y ago

The real problem with these kinds of posts is the equivocation in the word "dead". People wanting to defend languages (also APL lately) want to implicitly use a definition something like "0 people are using it and no work is being done in it", but by that standard you can't ever declare anything dead. That doesn't make the definition "wrong" but it does make it not useful. The purpose of a definition is to split the relevant set of possibly values into at least two non-empty sets. Other people are looking at the first and second derivatives of how many people are using it, how popular it is now compared to its height (in the programming language world it's already a problem if your "height" of usage isn't right now), and the likelihood of it ever coming back. From that point of view, Perl 5 is, if not dead, certainly very close. To me, most tellingly, Perl 5 has no plausible path that I've heard for acquiring some unique value proposition that can give it a new lease on life. As I said in https://news.ycombinator.com/item?id=26567151 https://news.ycombinator.com/item?id=26567151 , in a lot of ways Perl's biggest problem right now is that it won. It convinced people that its way was good, and as a result, Perl's previous value proposition has been incorporated wide and far in other languages. The only time I pick up Perl now is when I have the need for a seriously heavy-duty string munging task that fits into about 200 lines, and I get huge wins from the RE syntax in Perl. And by time-of-use, Perl is probably my "best" language, the one I've used for more clock time than any other. Even so, that's where I am in 2021. I would encourage the community to either decide that it's OK just continuing on as it is, or decide that it wants to try to find that new unique value proposition that will give it some sort of unique value in 2023 or 2024. But there isn't an option where Perl continues along as it is and it experiences some sort of burst in growth. You have to pick one, you can't get the advantages of both.

newaccount2021 5y ago
if people want to try to quantify "dead", a good place to look at is activity on cpan https://metacpan.org/recent https://metacpan.org/recent many packages I rely on have weekly updates
deleted 5y ago
[deleted]
justinator 5y ago

bachmeier 5y ago

What I wish would die is discussions of the death of languages. It's as useful as classifying people as good and bad athletes. Everyone is better or worse at some sports, and the threshold for switching from good to bad is purely arbitrary. It's better to have discussions with substance. "Perl job advertisements are down 34% in the last five years" might be useful. "Perl lacks libraries to do [task]" might be useful. "Perl is dying" isn't.

oblib 5y ago

I rewrote all my Perl app code in JS to run entirely on the client side years ago but Perl is still my go to server side tool. For example, I used to use HTML:Template, now I use Mustache.js. I'm quite sure I could do most anything I do with Perl with Python instead but since that would be pretty much the only thing I'd use Python for I'd spend more time learning how to do it than is necessary. I still use CGI.pm for a lot of what I do on the server side, which is not very much anymore. But for what I do use it for it's very good at and I've never had a problem with it.

htrp 5y ago

I think the business life cycle is also a useful analogy for languages at some point no new software should be developed in a given language and you should just be maintaining existing code bases corresponding to managed .decline

pram 5y ago

The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness. Starting today I'd obviously have learned JS or Go or Java or Rust or Python instead. Perl in 2021 probably seems like some curious antique like AWK, if they've even heard of it. That is the real problem I think. There is just no good reason to use it, and thus learn it. It doesn't do anything better than the alternatives. It's not "dead" but there is very little new blood entering the scene. It's a retirement home.

tyingq 5y ago
I imagine the old "Command Line Tools can be 235x faster than your Hadoop Cluster" story still applies. That is, there's probably a fair amount of data processing that could be done well with Perl (or awk, etc).
bluedino 5y ago
>> The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness. It was _the_ choice to use to write web pages in at one point. I remember installing RedHat Linux, writing a support 'forum' message board thing in Perl, then chucking it away as everyone was starting to use ColdFusion, PHP and .NET
- cyberge99 5y ago
  CGI was the way back then (still is in a way).
oneweekwonder 5y ago
> Perl in 2021 probably seems like some curious antique like AWK Sure you can call awk an antique tool being 44 years old, but its available on almost all unix-like systems even on router running busybox or bare minimum containers using alphine. So its definitely a personal nitpick of mine calling a very relevant tool an antique.
- shagie 5y ago
  Somewhere, I've got a book for programming awk. It's got some really neat things in there that are non-trivial awk scripts from yesteryear. I could see that being useful in the 70s or 80s... but not today. No-one writes awk more than a line or two today that's nestled in some ci script that is never looked at again. Yes, the tool is ubiquitous - its everywhere. It also happens to be part of the standard of what is on a machine which keeps it being used for those two liners. However, people aren't writing applications in awk anymore. Similarly, perl is going to go the same way. It's going to be useful for those 10-20 line data transformations that are in some data pipeline for munging data. But its not something that's continuing to grow and find its way as a first choice. Writing a new application in awk is something that people do for the exercise - much like going and doing your own primitive photography with a cyanotype. It's done as a "yes, I understand it enough to do this complex thing." Perl is a bit further back... it's developing your own film. There are still some people who do that as a matter of their business - but its not a first choice anymore. Cyanotypes and doing your own darkroom work are things of antiques in today's age. They're not gone - but doing things in them is more like going to the pioneer town and seeing how it used to be done rather than a practical choice for today.

streamofdigits 5y ago

Billion dollar companies have been built on perl[0]. So let us not seek to fix the blame for the past, let us accept our own responsibility for the future. Seriously though, how large a collection of programming language ecosystems does the world want or need? How many equivalent stacks, all solving the same problems with more or less the same patterns and concepts? Just a thought: Open source communities could benefit from less dispersion of energy and talent, less endless re-invention of the wheel, less endless "not-invented here syndrome"... [0] https://www.slideshare.net/cmnunes/bookingcom-perl https://www.slideshare.net/cmnunes/bookingcom-perl

dreyfan 5y ago
There’s far more venture capital than innovative ideas and the business problems are rarely hard to solve. Engineers get bored so we have a constant flow of new languages, frameworks, and lately, an overwhelming focus on tooling and infrastructure. At the end of the day, most companies are just generating dynamic HTML after performing some rudimentary CRUD database operations. It’s disappointing so much time and money is spent only to arrive at the same place that /cgi-bin/ and a perl script solved over two decades ago.
mywittyname 5y ago
>how large a collection of programming language ecosystems does the world want or need? There are many problem domains that can be solved by computers, and having a language specific or well suited to that niche can be a productivity boon. As long as humans continue to discover new problem domains in computing, they will continue to develop new programming languages to work in them more efficiently (and existing languages will expand to try and fill that niche).
- streamofdigits 5y ago
  yes, I am not arguing for a single language. But many of the domains you mention are actually intrinsically similar once you map them to the underlying information flows. This explains for example the extreme ubiquity and longevity of things like relational databases and SQL. There are several genuine and orthogonal domain "dimensions", e.g real time systems or parallel processing etc, but I would say that is a handful, not the multiple dozens even hundreds of idioms we use to program digital devices...

xdfgh1112 5y ago

Weird timing considering the community is actually dying right now - lots of talented people have left recently and many of my pro-Perl friends have stopped using for good.

doomvox 5y ago
Don't know exactly who you mean, but while sawyer x has stepped down recently, the dev team seems to be in good shape-- they've adopted the steering committee idea, and are using an informal RFC process to make decisions about new features.

bloak 5y ago

I use Perl all the time for short programs, up to a few hundred lines. The main advantages of Perl are that it's already installed on all the systems I use and the language itself is not changing: Perl scripts I wrote 20 years ago still work, and I have a vague hope that Perl scripts I write today will still work in 20 years' time. Maybe Python is now stable enough for me to consider it as an alternative to Perl but I've bad experiences trying to run Python scripts from 20 years ago. In any case, Python is less concise for the sort of programs I write, and although Perl has a reputation for being unreadable it really depends on who's writing it. I write in a subset of Perl, with "use strict", that I find to be readable. I find Perl stops being convenient at about the point where you need complex data structures and modules.

Thaxll 5y ago

Perl is pretty much dead, actually I've never seen or touch or heard new project being built in Perl for the last 10 years. Python took over.

stevekemp 5y ago
Perl is used in the background for lots of glue, and integrations. But I don't think it was python that took over from Perl. When I think of the kinda web-applications I was writing they got replaced by Rails, PHP, and similar.

CodeWriter23 5y ago

I’ve coded in Perl since the late 90’s up until about 3 years ago. Thought Dancer and Dancer2 were awesome web frameworks. Especially loved making my own app-specific DSL. Then I took a consulting gig and the framework server side was Laravel. I switched and never looked back. I’m even porting one of my Dancer2 backends to Laravel. My main reasons: 1. Laravel has so much momentum, the tooling is so superior to Dancer2 that the Dancer2 crew will never catch up. The schema migration management alone is a killer app that will drive switching. And tons more. 2. In patio11’s post about selling Bingo Card Creator, he indicated implementation language is a key consideration for a buyer. They want to be able to draw from a larger and possibly less expensive talent pool for maintaining and extending the software. PHP wins on both of those metrics. 3. I’ve reached the point in my life where I want to do stuff WITH as opposed to do stuff TO my applications. Size and cost of the Talent pool is relevant in this way to me for the simple reason I know there aren’t enough hours in the day to do it solo. I always wanted Perl to make it back into the mainstream. It will never die. But to me at this point, Perl is as impractical as some of my crazy ex-girlfriends. I bid it the same affectionate farewell.

mmaunder 5y ago

While the authors accusation audit is impressive, I can assure you, as a CPAN contributor and someone who has launched some very successful Perl web apps, that Perl is in fact, completely and utterly dead. It died well over a decade ago when all focus moved to Perl 6 which didn’t emerge until recently. Everyone moved on except a hardcore group of advocates. They aren’t coming back. If a new language and community emerges that happens to have the same name, I’ll certainly take a look. That hasn’t happened yet. And it’s a damn shame because the mod_perl list and community had some killer talent in it that was creating the most innovative and heigh performance web applications out there. I created WorkZoo in Perl which was a very high performance job meta search engine and was one of Time Magazines top 50 sites in 2005. What happened to Perl is a damn shame. Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.

kamaal 5y ago
>>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled. Who uses php these days? I haven't heard any one start a new php project in years. Ruby seems to have gone the same way. Python seems to have won the backend game, which actually makes sense as Python today is bloated like how Perl was once. And these days it feels like Perl with tab indentation. No wonder it fanatic following these days. Frontend game is now owned by Node, ReactJS, JS etc. Who uses php to do anything? In fact I don't know of a single college kid I've hired who has even looked at php let alone used it.
- nrdvana 5y ago
  WordPress, Drupal, Magento, Joomla, OpenCart and lots of other open source community CMS and online web-store type things are built on it. Sadly it will never die because it has Facebook pouring money into it.
- mgkimsal 5y ago
  Why is "college kid skills" relevant for anything? Do you make tech and business decisions based on what your incoming jr people want to do? Many people in my circles use PHP for ... lots of stuff. I just got back from a PHP conference, and saw hundreds of people there are using it. "Python seems to have won the backend game" - I'm really curious where you get that impression from. I can't imagine it's relating to publicly available web servers. That's not a total view of everything, of course, but... absent other numbers/studies/reports, it's really hard to draw any conclusions that aren't just based on personal experience.

netcraft 5y ago

What I would like to see in posts like this is a description of the kinds of programs the author thinks are great candidates for this language over others, maybe with an acknowledgement of the other options and a comparison of why (in this case) Perl might be a better choice. I see a lot of the things listed that they think are strengths, but many of them are shared by other languages that don't have the negatives (even if a lot of those negatives are just perceived) - so why should I choose Perl in 2021? I have professionally written a few languages in my life that the zeitgeist would consider "dead" - what I always see in those communities is a lot of people crying that they aren't dead like something out of monty python - and that its "actually a great language", but no real pitch about _how_ that would apply to the prospective people who might pick it up. These conversations always come across as delusional, fan-boyish, and the opinions of people who feel pot committed to the language they've spent so much time in and are not willing or able to pivot, begging people not to think that they chose poorly. I truly don't know if this applies to Perl, I certainly have opinions long held and maybe things have changed over the years, but in a world with so many great options today, to make a dent you have to paint a picture for people to convince them to give it a shot.

debacle 5y ago

I still love Perl. If I had the opportunity to work on an existing Perl project, I would relish the nostalgia. I would never, ever use Perl for a greenfield project unless there was a library that was absolutely crucial to the development, for many reasons. Perl 6 was so disastrous to the ecosystem that it effectively killed the language. If 20% of the effort that went into Perl 6 had gone into keeping the language fresh, I think Perl would still be part of the conversation today.

bloblaw 5y ago

Perl is simply a tool. I still use it all the time for small scripts and automation. I know Python, Go, C#, and a bunch more....but I reach for Perl when the task calls for processing lots of text, or quick automation. Others might reach for Python or Ruby or Go. For me it's a better bash script, a better grep, a better awk, a better sed. That's what Perl was designed to be, and I don't think any other scripting language matches it for that purpose. It is not a tool to build desktop applications or the first choice for web applications in 2021. But it is still extremely useful for its niche...processing data/logs/text, or system administration tasks. It really shines there and that's how I use it. It's another tool in my toolbox, and learning Perl has made me more productive and I still reach for it today.

brtastic 5y ago
The tool analogy is flawed. Languages that move fast and break backward compatibility are tools, but organic. If you leave them in your toolbox for too long they start to rot. This does not apply to those languages that do not get updated (bash?) and that does not break backwards compatibility (perl? but without CPAN modules). I know that my PHP tool has rotted even though I was actively using it. It moves too fast and the frameworks I was using are no longer any popular - should've learned symfony instead of yii, now laravel is taking over

coldtea 5y ago

Nope, they're accurate. But I guess hope is eternal.

moedersmooiste 5y ago

Booking.com is the only big website I know that still uses Perl...

doomvox 5y ago
Adultfriendfinder, cams...
vajrabum 5y ago
Craigslist.com also still uses perl.
- jzawodn 5y ago
  s/\.com/.org/

Animats 5y ago

There should be a convention where the APL people, the LISP people, the Perl people, and the Pascal people get together and talk about the good old days.

int_19h 5y ago
I miss Algol 68. ~ (Seriously, though - in retrospect, it feels like most of the complexity that the language was criticized for is standard fare in PLs of today, often in the same shape.)
manbart 5y ago
Include Tcl and I’m there!
justin66 5y ago
I'm a little freaked out by the prospect of any crowd where the Perl people are the youngest ones.

chefandy 5y ago

The only reasons I could think to use perl over Python are regex execution speed and 'maybe' infeasibility of accessing PyPI so you'd need more built-ins, but still have plenty of disk space... though I haven't done any feature parity comparisons there. Am I missing anything? I liked Perl back in the day and used it a lot but even my old sweet-jesus-what-was-I-thinking Python code is a LOT more readable than my cleanest old Perl code. I'd be curious to hear from folks who've also been deep in Python and Perl but stuck with Perl rather than Python— different use cases? Coding styles?

extortionist 5y ago
My job is split between maintaining a giant legacy perl codebase and doing new dev work in python. I vastly prefer python overall, but perl's still the best when you need quick one-off scripts to tear through log files or do some quick regex subs on a bunch of files. I don't think python has an equivalent of 'perl -p -i.bak -e 's/foo/bar/g' *', for example (which will do in-place regex substitutions on whichever files are passed in, additionally copying the original files to 'original.ext.bak'). The regex syntax is also bit more streamlined in perl, so I find it quicker and easier to throw together a script that's just doing regex stuff in it. A simple example: >> $string =~ m/(pattern)/i; >> my $match_text = $1 || ''; >> $string =~ s/pattern//gi; >> import re >> match_obj = re.find(r'(pattern)', string, flags=re.I) >> match_text = '' >> if match_obj is not None: >> match_text = match.group(1) >> string = re.sub(r'pattern', '', string, flags=re.I) Of course, the same magic that makes perl great for those one-off kinds of scripts makes it less than ideal for complex or long-living scripts that need to be maintained by multiple people, in my opinion.
- chefandy 5y ago
  No doubt: the regex syntax in Perl is most efficient. I can envision using Perl more if I ever got back into a command line focused text manipulation workflow. I tend to use lighter-weight tools for things like your one-liner— I believe `sed -i '.bak' "s/foo/bar/" *` is equivalent, but I disagree with the neckbeard purists who say you should always use the lightest-weight tool possible. If you're using Perl anyway and Perl can get the job done with the smallest cognitive load, that's the correct tool.

cafard 5y ago

I don't often write Perl these days, but I did this week. I was amused to find that I was using "def" rather than "sub" to declare functions.

chipuni 5y ago

A good measurement of whether a language is "dead" or not is the TIOBE index: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Is Perl dead? No, it's still among the top-20 programming languages. Is Perl dying? Yes; it dropped 8 places among the top-20 programming languages.

Hjfrf 5y ago
The list is based on search engine hits for "x programming". That's probably fine for comparing c to c++ or perl. Searches for "scripting" or "coding" instead are not counted, which probably explains shell scripting below languages 20x less popular if you search by the name alone. Powershell at ~40, bash not even top 50. You'd assume both are dead from this list.
justinator 5y ago
Oh so Perl is owned by Schrödinger?

giantrobot 5y ago

Perl isn't dead but its usage is not growing and I don't see any reason it will ever grow again. Unless you're an old school Perl hacker there's little reason to start a green field project with it today. I say that as someone that has written a lot of Perl over the years. It turned out to be an awesome language for CGI apps in the early days of the web (the reason I learned it). It was also a better system administration/automation language than some bash/awk/sed/grep amalgamation. For me at least it fell down once you got over a few hundred lines. The TMTOWTDOI led to your own (or at least my) code being internally inconsistent and the lure of its shorthand meant coming back to old code took some effort to understand. I moved from Perl to Python and it helped immensely with both those problems. Once I grokked Python's regex I could do everything in Python I used to do in Perl with the same speed but half the effort. I don't see any attraction of going back to Perl. It was a nice tool for a time but now there's better tools (IMO). So once old deployments of Perl apps/tools are replaced I really don't think they're going to be replaced with Perl.

G3rn0ti 5y ago

Eventually every technology will age and die after some time. Today, you may be proud of your intimate knowledge of Python, Golang, C++ or even JavaScript. But in 20 years from now people will have gone on and you might be left behind. So to all young and smug whippersnappers here: Memento mori!

justinator 5y ago
What you need to find is a willing host to totally monopolize. JavaScript just isn't going away from the browser in my lifetime and JavaScript started out as a completely hobbled language that still has major warts. Perl doesn't have that. Reads in strings, do stuff, outputs strings? Welcome to Unix!

sethammons 5y ago

We managed a several thousands node cluster of perl services. We took several years, but we recently finished migrated all of this off from stateful Perl to stateless Go all the while growing rps volume 40% yoy and migrating datastores as we scaled those too, continually improving stability and availability, adding features, and scaling the org from a few hundred people to a few thousand. We are now 100% off perl for our critical path. Perl is not on my resume :)

arunix 5y ago
What does stateless Go mean?
- sethammons 5y ago
  Stateful means state is stored in memory or on disk by the processing service. Stateless means that state is stored distributed to multiple nodes and can be recreated or that there is a design such that no state is needed. In the first case, a node dies and information is lost, in the latter, no information is lost. This allows for greater scale by often saving resources per request and increasing resilience. A concrete and simple example: an api request comes in and you call n dependent services before responding. If any of those calls fail, the entire response 500s, if ok, respond 200. Instead, make this a job with a 202 response with an id returned and use a distributed queue and workers to async process the request and allow the job results to be queried by job id. Now any node failures are invisible to the client.

0xbadcafebee 5y ago

I still use Perl all the time for random tasks. It is exceedingly fast and simple to create very powerful programs using stable libraries, and all the legacy code still works. It's the most handy general purpose scripting language, period. And you can run it anywhere. I don't use it for "portable" things, which is funny because it's more portable than any language I can think of. I write things in Python if anyone other than me has to support it or run it, and Bash if it's just going to be embedded in a system where I don't want to make Perl a dependency. But to do something powerful and fast just for myself? It's Perl, baby.

MarkusWandel 5y ago

On my Linux system I could, if I wanted to, write programs in (the subset of bash that is) Bourne shell, awk, plain old 1970s vintage C, implement text filters in sed... all these are antique things that don't need a vibrant user community. They just need to work well enough to support existing stuff written in them, and for an occasional quickie script by old farts who know how to use them. Why should Perl be any different? It'll be decades before a practical system won't have a Perl 5 compatible /bin/perl on it. So if I know Perl well enough that I can hack something up in 5 minutes, and Perl is there and works, how is it alive or dead? It just is. And that suits me just fine.

mongol 5y ago
Good point. The alive / dead metaphor is not so useful to descibe the language itself. Perhaps it is the community that should be described as alive or dead. The language itself is just a tool. It never was alive, but as long as it works, it is useful for those that choose to use it. Just like a hammer can be useful long after the toolsmith that made it died.

alexeiz 5y ago

I haven't used Perl in ages. Seeing all these new features in Perl 5, I want to use it again. I've looked at Raku and didn't like it. I think it went astray and it doesn't fit the spirit of Perl (being practical).

uxp100 5y ago

What's the replacement for Perl based Verilog metaprogramming in the Intel (I think) style? I'm being a little cheeky, but that is a use-case for perl at a few of the places that make the processors that the web-frameworks that no longer use perl run on. I no longer work at a semiconductor company, maybe they're moving away from that, but I'm not sure what would replace the in-line perl in verilog files that use perl as a pre-processor.

rektide 5y ago

I would love to see more innovation in scripting languages. Nothing (I've seen) comes as close to perl for swizzling together a decent, capable, handy programming language with a variety of system binaries & other shell scripts. There's a couple efforts like shell.js[1] or the far simpler/more-contemporary zx[2] to give shell-scripting like ease to js. zx's core is just at tagged template string for running system() calls, basically, ex: $`echo 2+2`. I still find the experience pretty sub-par compared to how shell & scripting first languages like Perl are. Perl is just super powerful, keeping a foot in a more user-land like environment, versus the totalizing experience of libraries. Why do you need to pick a http client library to use when everyone is already quite intimate with curl & it's already on the system? Somehow coding keeps taking more turf, but I feel like Perl's scripting was extremely glorious & largely un-reproduced. Perl is still some of the best "glue" the planet has seen. And glue, as we've read a couple times on HN[3][4], & which I agree with, is really important, dominates what we build. To the topic itself, as a Debian user, I appreciate Perl, but I wish it weren't on my OS taking up ~20MB of space & being more & more offbeat, but it's probably never going away. Not sure why it irks me that my computers will all need that ~20MB of Perl + Debian perl libraries. And it is pretty cool how debuggable & visible the Debian tools often are, because they're scripts, not compiled programs, by & large. But there's a lot of operators to lookup & a lot of implicit variables to remember in Perl programs, and it's a reminder how offbeat Perl is, every time I poke my head in. [1] https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs [2] https://github.com/google/zx https://github.com/google/zx [3] https://news.ycombinator.com/item?id=27486706 https://news.ycombinator.com/item?id=27486706 https://blog.metaobject.com/2021/06/glue-dark-matter-of-software.html https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft... [4] https://news.ycombinator.com/item?id=27880183 https://news.ycombinator.com/item?id=27880183 https://www.oreilly.com/radar/thinking-about-glue/ https://www.oreilly.com/radar/thinking-about-glue/