> 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.
> 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.
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.