[deckard1]

> perl has been the same since 2002

if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5.

https://en.wikipedia.org/wiki/Perl_5_version_history

Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks.

> Another issue is just the bit rot of cpan.

Sure. But NPM exists. There is unmaintained JS code that was created only 6 months ago. Github is littered with orphaned garbage. I could probably find a dozen or so packages within my company's node_modules folder. Perl is less used today so of course the packages are outdated. But in terms of purely giving a crap... no one gives a crap about NPM. No one. It's largely abandonware on the day it's created. I never really found that sentiment to be the case with CPAN. You had to make an effort to get a package out there. The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.

I don't use Perl much these days. But the hate it gets on HN is insane. It's had a lot of what people consider "modern" features as far back as the 1990s. I really haven't seen a single thing Python, Ruby, or PHP have done that much better.

[simias]

I haven't seen that much hate for Perl on HN. I personally used it for quite a while and liked it a lot. But I think it's reasonable to consider it a legacy language these days, next to Fortran, Ada and TCL.

Are these languages still used in some niches? Certainly, TCL is still big for scripting ASIC/FPGA design tools last I checked. Similarly Perl projects will still be used and maintained for a long time, it may well outlive us all.

But it's very hard to defend using Perl on a new project these days. I know I wouldn't. I have very little love for Python but I'd go with it instead of Perl almost every single time now. There was a time where CPAN was the killer feature of Perl. Now Python caught up while, as the parent points out, CPAN is slowly rotting due to unmaintained packages. NPM being a mountain of trash is entirely irrelevant frankly. And it's not like in its heydays every single CPAN package was a marvel of software engineering either.

>The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.

See, even you use the past tense. There's no argument that DBI is great. That's not the point. Languages survive not because they're good or bad, but because they have community and corporate support. That's why PHP holds up pretty well while Perl slowly falls into irrelevance. We can lament it, we can try to fight it, but can't deny it.

[bch]

Tcl is (last I knew) still remarkably big on “the edges” of networks: f5/a10 devices (iRules scripting[0]), used to be (is it still?) used for Cisco iOS scripting[1], was used as the glue language for Tealeaf session/network capture[2] (when it was deployed as on-premises installation ), and control language for Argonne National Lab cluster control[3]...

[0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...

[1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...

[2] https://help.goacoustic.com/hc/en-us/articles/360043736414-P...

[3] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf

[blacksqr]

Also heavily used in banking and trading systems (Fidessa).

[blacksqr]

Also heavily used in software testing, including DejaGnu for Linux binutils.

[blacksqr]

Also heavily used in health care information management (Infor Cloverleaf).

[blacksqr]

Chip design, internet routing, compiler testing, finance, health care.

A legacy language that's only used anymore when basic infrastructure really, really has to work.

[zem]

> I really haven't seen a single thing Python, Ruby, or PHP have done that much better.

explicit function signatures for one!

[tyil]

Perl has had those since 5.20, although they're optional.

[py_or_dy]

> Perl maintains strict backwards compatibility. I can run code that was written decades ago.

I used to spout that off too, but I now think it is just a myth. When the leader/creator of the language abandons it and it sits there stagnate for years, what other "feature" can you advertise? I know, "strict compatibility"! I saw it as a feature as well and even used it as an excuse to not learn python.

But even worse it has tainted an entire generation of small business perl dev shops. They seem to think that they can't move to another language because every couple of years back compatibility in language X breaks and at the same time spout off how their perl CGI scripts from 1998 still work fine ("fine" because it hasn't been hacked yet). Ironically doing this all from their windows laptop that has broken compatibility through many release cycles.

Breaking compatibility and refactoring is a sign of health, not death! But now these old school dev shops have large customer bases on old perl who's customers are not used to paying for any kind "upgrade" (and now they never will be). Contrast that with every now and then on /r/django someone will post a question like "my development firm is wanting to charge me $3k to upgrade from django 1.2 to 2.0 before they will add any new features to my web shop. Is that a good deal?". Its just a fact of life now. Software needs to be upgraded. The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".

It's the same with python 2.7 as well. That is because it is dead, it now has "strict compatibility"!

> I really am curious what features you think Perl 5 lacks.

That's a good question. Really, perl can do anything that python can. So what gives? I think the biggest thing that I struggle with just goes back to the "community". I'm trying to stay brief as not to out myself or my last company, but in most cases I was given requirements for a new project and I was off on my own. That's fine. But sometimes I'd be given requirements for a new project and then get micromanaged. As in literally told how to organize the entire project down to little bits like "when a user registers a new account, a function will return a random string 6 characters long and be sent via email to the user and this password will be stored in clear text". That is not the exact case, the real case belongs on codinghorror.com.

But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world. I'm sure some perl guys will try to chime in and disagree but it is true. I have asked several question on /r/perl to get advice on really stupid architectural requirements but got 0 responses. The same goes for the perl mailing lists and irc. Its all dead. Many times I've posted to python lists pretending to be making a flask app or something just to get some advice on some webdev best practices, etc, not easy questions but just looking for a discussion. It's embarrassing on the perl side.

[kbenson]

> Breaking compatibility and refactoring is a sign of health, not death!

That is entirely dependent on what type of project it is, and what it's used for. Software that is not getting new features added and expected to work as it was and maybe get the occasional bug fix has no need for refactoring, and refactoring is almost definitely going to be detrimental before it possibly yields benefits.

A simple example of this is core Unix utilities, firmware, etc. When the scope is kept small, and the engineering is done well, those just work, and are expected to keep working. People aren't clamoring to refactor cp and mv. It is harder to keep these constraints sane as the code and project increases in size though.

Now, the ability to somewhat safely refactor is a sign of health, because it means there's high understanding of the scope of the code/project, and well known ways to test. That's a far cry from actually doing so, and I think you would be hard pressed to find a project that was undergoing a major refactor and breaking compatibility that I would look at and say "oh, they must be so healthy, because that's what healthy projects do, break backwards compatibility and refactor." The only reason to actually take on those tasks is because you have problems you think can't be fixes without them, which is not an indicator of healthiness.

> The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".

Just because your experience is web apps doesn't mean that's all there is. Do user facing applications that process user input need a lot of updates to make sure they stay in-line with security needs? Yes. Is all software user facing? Does all software need to support something as complex as a browser? No. Different classes of software have different classes of requirements. Does "it will still run on a new interpreter 20 years later" sound interesting to someone doing web development? Probably not. Does it sound interesting to people running system software, that often pay hundreds of dollars per system just so they can run an OS that back-patches security problems so they have a stable running environment with minimal change for 5+ years at a time? Hell yes it does.

But that's okay, you want current, modern Perl web apps? Use Mojolicious. It has a well defined deprecation policy, and you're forced to update your code if you stay up to date with it and be secure, just as you would expect from any Modern web app that takes things seriously (because some problems well be architectural, and may require user changes to fully accommodate).

> But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world.

I'm not really sure what this has to do with Perl or Python. This is security, systems, and web best practices, and the language is irrelevant to the example. You shouldn't need to go to /r/python to tell your boss that storing a password in plain text and with bad requirements for users is bad practice. Sure, it might work, but I think it's more indicative of cargo-cult behavior, and spreading it. If I'm building a Perl app, or a Haskell app, or Rust app, I should be able to pop into /r/python or anywhere else I expect someone might be around with experience, ask about best practices, and get a response that is not couched in "we just do X in flak/django whatever". If someone isn't explaining why storing passwords in plain text is bad, then they aren't really giving a good answer.

> The same goes for the perl mailing lists and irc. Its all dead.

That's now my experience. I don't bother going to IRC often, but I get helped whenever I do. IRC still seems to be the preferred medium for Perl devs to congregate and communicate. Not much else I can say about this, you didn't really provide much info other than it didn't help you and there's nobody there to help you, and my experience is different.