5 ms·

> FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011. Because it works. Scripts/software that works does not experience bit rot. As l

> FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011. Because it works. Scripts/software that works does not experience bit rot. As long as it works, people will continue to use it. Edit: OK, fine. It seems the downvoters are convinced that the code does in fact experience bit rot, and spoils with time. Probably like fish.

bifrost 7y ago
Sure but there's a reason that development has moved off of Perl.
- lilSebastian 7y ago
  > Sure but there's a reason that development has moved off of Perl. Why don't you specify this single reason you allude to?
  - luckylion 7y ago
    That's just a saying, it doesn't mean that there's one specific reason, it means "that didn't happen by accident". I think there are plenty of reasons, and they work to reinforce each other.
    - lilSebastian 7y ago
      > That's just a saying, it doesn't mean that there's one specific reason > a reason Singular, in English that means there's a single reason. > I think there are plenty of reasons, and they work to reinforce each other Care to expand on this? Genuinely interesting, a thread where people complain about a language and they are so careless with the language they use to try and get their point across...
      - luckylion 7y ago
        > Care to expand on this? Not particularly since you seem very combative... but here it goes, from the top of my head: without Moose/Moo etc OOP is (was? no clue, I don't follow development any more) just cumbersome and archaic (and with it you'll run into strange things when you hit errors), support in modern IDEs is lacking, there are few developers and therefore a smaller community, it's often not among the officially provided SDKs etc. Those are all interconnected. You can't easily hire Perl developers. Nobody wants to pay large sums to compete about the few there are to provide an SDK for a language that is on its way out. Nobody wants to work with a language that's not really supported by businesses. There's no large community to improve tools. Of course, I don't mean literally nobody, just very little. It's a vicious circle. I liked Perl (it has a special place in my heart), I've written a ton of stuff in Perl, some of it I still support, but I can't say that I've missed it in the last five or so years since I've stopped actively writing it. I still occasionally log into the perl-focused community I used to frequent and they are still getting about a post a week. I never gave Perl6 a chance, simply because it would be a switch to another language where knowing Perl didn't really transfer, so I might as well go where the music plays. And yeah, CPAN-modules are nice and all, but a lot of it always looked to me as if written for a contest of clever code, not to be read & understood easily.
        lilSebastian 7y ago
        > Not particularly since you seem very combative Asking people to back up what they say is 'combative'? Nothing else in this post has a ring of truth either
  - bifrost 7y ago
    Its a saying, but since you're being pedantic I'll use my personal favorite example -> Having to use mod_perl or cgi/fcgi is awful.
    - claudiawerner 7y ago
      Most people who develop web stuff with Python end up using FCGI/WSGI to use with nginx anyway, so I'm not sure what this complaint means.
      - lilSebastian 7y ago
        An attempt to justify their rant with 1990s era perl examples
    - lilSebastian 7y ago
      You don't have to use either of these. Was the last time you used perl in the late 1990s?
    - Grinnz 7y ago
      Modern web development doesn't use these, and mod_perl is certainly not recommended anymore - CGI still has its uses, but don't use CGI.pm. A modern webapp is written in Mojolicious or a Plack based framework, and they can all deploy transparently via a standalone server, or any PSGI or CGI server, or even mod_perl or fastcgi if you really need to.
- notyourday 7y ago
  And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does. Would I write an API in perl? Nope. Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely. Mostly because I will write a few hundred lines of code for existing CPAN modules to solve the problem that I have, letting me to move on to doing something else. I like boring tools that just work. In 99.99% of the times the tools/whatever you are writing is not inline, does not need to have amazing performance. It just need to work and be braindead simple. Perl excels at that. I still daily use code that I wrote over 25 years ago and modified it a couple of times since that point ( integrating git ). Edit: Can't reply below so I will reply here: Re: I would not write an API in perl. > I see you have not tried Mojolicious. I have seen it, tried it, got excited about it and immediately came to my senses because I asked myself "Why on earth would I build or advise people to build an API in perl? It is slow. It is bad for concurrency. It probably has a pile of corner cases that I'm or some other people are going to discover. If I need to ingest something via web I will throw a simple nodejs app. Millions played with it actively in a "web" sphere, and hit most of the corner cases. There are thousands articles on stackoverflow and we have dozens of skeleton servers that already have all the needed foundations, including federated databases that support live password changes, traffic sharding, online promotion and switches, dynamic reloads, do-at-most-once queues, do-at-least-once queues, etc etc. Why would I want to reinvent all of this when the job of the API is to get the stuff and if the question cannot be answered via a couple of lookups push the request to a worker?" Re: CPAN in 2019 > n 2019, I can only think you haven't looked around much recently. Maybe. I have not seen it to be the case two months ago.
  - jerf 7y ago
    "I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does." In 2010, that may have been true. In 2019, I can only think you haven't looked around much recently.
  - Grinnz 7y ago
    > Would I write an API in perl? Nope. I see you have not tried Mojolicious.
- proverbialbunny 7y ago
  For people who are curious as to why people moved to Python. Some will say because college kids are taught Python, but I think that is a side effect. Perl is an old language, pre OOP. It's a language from the 90s, when everyone was hacking together code not knowing what the future would be like. There is a lack of organization. Perl is like C in syntax, features, and in speed. Python is like C++. Every failing you can find in Perl stems from it being a PP language first, from dirty code to kids not learning it in college. Raku attempts to address every failing of Perl, yet be better than Python. If it succeeds, who knows, but I hope it gets at least a chance to make something of itself.
  - sverige 7y ago
    Fifteen years hasn't been enough of a chance?
    - proverbialbunny 7y ago
      15 years? Raku just recently came out. Perl was the popular language once upon a time ago. But it stagnated while new technology came in to replace the old.
  - axaxs 7y ago
    People like easy to read languages. Many years ago, when I first got back into development, I decided to choose to learn Python or Perl. After doing some research, it seemed Perl was more widespread. But Python was easier to read, so I went that route instead(luckily). I think the popularity of Basic and Golang vs their competitors of the time help prove this point. People say that Go is only popular because of Google, but I honestly feel if Rust and Go switched owners, it would have played out the same way.
lonelappde 7y ago
The environment changes, and old programs need to update to keep up with new data formats and remote services and security threats.
- notyourday 7y ago
  If you do not build gigantic monolithic applications and instead stitch together lots of things that do just one thing each using jobs engines and APIs for injecting data and collecting data most of the worker updates become trivial - minutes rather than months. It becomes irrelevant if a worker is written in perl, python, C, java, scala, etc.
curryst 7y ago
I would argue that becoming "legacy" is akin to bit rot. Sure, it still runs, but everyone that knew how it worked has left the company, and it's written in a language that is no longer in vogue and will require specifically hiring people with that skill to maintain. As a counterpoint, I think we can both agree that writing production software in one of the toy languages that pops up on HN frontpage every day is a bad idea. Writing in a language that is old enough that it has become niche has many of the same issues. It doesn't really matter whether the software is poorly understood because the language is new enough to be niche or old enough to be niche; the outcome is the same.

bifrost 7y ago

Sure but there's a reason that development has moved off of Perl.

lilSebastian 7y ago
> Sure but there's a reason that development has moved off of Perl. Why don't you specify this single reason you allude to?
- luckylion 7y ago
  That's just a saying, it doesn't mean that there's one specific reason, it means "that didn't happen by accident". I think there are plenty of reasons, and they work to reinforce each other.
  - lilSebastian 7y ago
    > That's just a saying, it doesn't mean that there's one specific reason > a reason Singular, in English that means there's a single reason. > I think there are plenty of reasons, and they work to reinforce each other Care to expand on this? Genuinely interesting, a thread where people complain about a language and they are so careless with the language they use to try and get their point across...
    - luckylion 7y ago
      > Care to expand on this? Not particularly since you seem very combative... but here it goes, from the top of my head: without Moose/Moo etc OOP is (was? no clue, I don't follow development any more) just cumbersome and archaic (and with it you'll run into strange things when you hit errors), support in modern IDEs is lacking, there are few developers and therefore a smaller community, it's often not among the officially provided SDKs etc. Those are all interconnected. You can't easily hire Perl developers. Nobody wants to pay large sums to compete about the few there are to provide an SDK for a language that is on its way out. Nobody wants to work with a language that's not really supported by businesses. There's no large community to improve tools. Of course, I don't mean literally nobody, just very little. It's a vicious circle. I liked Perl (it has a special place in my heart), I've written a ton of stuff in Perl, some of it I still support, but I can't say that I've missed it in the last five or so years since I've stopped actively writing it. I still occasionally log into the perl-focused community I used to frequent and they are still getting about a post a week. I never gave Perl6 a chance, simply because it would be a switch to another language where knowing Perl didn't really transfer, so I might as well go where the music plays. And yeah, CPAN-modules are nice and all, but a lot of it always looked to me as if written for a contest of clever code, not to be read & understood easily.
      - lilSebastian 7y ago
        > Not particularly since you seem very combative Asking people to back up what they say is 'combative'? Nothing else in this post has a ring of truth either
- bifrost 7y ago
  Its a saying, but since you're being pedantic I'll use my personal favorite example -> Having to use mod_perl or cgi/fcgi is awful.
  - claudiawerner 7y ago
    Most people who develop web stuff with Python end up using FCGI/WSGI to use with nginx anyway, so I'm not sure what this complaint means.
    - lilSebastian 7y ago
      An attempt to justify their rant with 1990s era perl examples
  - lilSebastian 7y ago
    You don't have to use either of these. Was the last time you used perl in the late 1990s?
  - Grinnz 7y ago
    Modern web development doesn't use these, and mod_perl is certainly not recommended anymore - CGI still has its uses, but don't use CGI.pm. A modern webapp is written in Mojolicious or a Plack based framework, and they can all deploy transparently via a standalone server, or any PSGI or CGI server, or even mod_perl or fastcgi if you really need to.
notyourday 7y ago
And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does. Would I write an API in perl? Nope. Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely. Mostly because I will write a few hundred lines of code for existing CPAN modules to solve the problem that I have, letting me to move on to doing something else. I like boring tools that just work. In 99.99% of the times the tools/whatever you are writing is not inline, does not need to have amazing performance. It just need to work and be braindead simple. Perl excels at that. I still daily use code that I wrote over 25 years ago and modified it a couple of times since that point ( integrating git ). Edit: Can't reply below so I will reply here: Re: I would not write an API in perl. > I see you have not tried Mojolicious. I have seen it, tried it, got excited about it and immediately came to my senses because I asked myself "Why on earth would I build or advise people to build an API in perl? It is slow. It is bad for concurrency. It probably has a pile of corner cases that I'm or some other people are going to discover. If I need to ingest something via web I will throw a simple nodejs app. Millions played with it actively in a "web" sphere, and hit most of the corner cases. There are thousands articles on stackoverflow and we have dozens of skeleton servers that already have all the needed foundations, including federated databases that support live password changes, traffic sharding, online promotion and switches, dynamic reloads, do-at-most-once queues, do-at-least-once queues, etc etc. Why would I want to reinvent all of this when the job of the API is to get the stuff and if the question cannot be answered via a couple of lookups push the request to a worker?" Re: CPAN in 2019 > n 2019, I can only think you haven't looked around much recently. Maybe. I have not seen it to be the case two months ago.
- jerf 7y ago
  "I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does." In 2010, that may have been true. In 2019, I can only think you haven't looked around much recently.
- Grinnz 7y ago
  > Would I write an API in perl? Nope. I see you have not tried Mojolicious.
proverbialbunny 7y ago
For people who are curious as to why people moved to Python. Some will say because college kids are taught Python, but I think that is a side effect. Perl is an old language, pre OOP. It's a language from the 90s, when everyone was hacking together code not knowing what the future would be like. There is a lack of organization. Perl is like C in syntax, features, and in speed. Python is like C++. Every failing you can find in Perl stems from it being a PP language first, from dirty code to kids not learning it in college. Raku attempts to address every failing of Perl, yet be better than Python. If it succeeds, who knows, but I hope it gets at least a chance to make something of itself.
- sverige 7y ago
  Fifteen years hasn't been enough of a chance?
  - proverbialbunny 7y ago
    15 years? Raku just recently came out. Perl was the popular language once upon a time ago. But it stagnated while new technology came in to replace the old.
- axaxs 7y ago
  People like easy to read languages. Many years ago, when I first got back into development, I decided to choose to learn Python or Perl. After doing some research, it seemed Perl was more widespread. But Python was easier to read, so I went that route instead(luckily). I think the popularity of Basic and Golang vs their competitors of the time help prove this point. People say that Go is only popular because of Google, but I honestly feel if Rust and Go switched owners, it would have played out the same way.

lonelappde 7y ago

The environment changes, and old programs need to update to keep up with new data formats and remote services and security threats.

notyourday 7y ago
If you do not build gigantic monolithic applications and instead stitch together lots of things that do just one thing each using jobs engines and APIs for injecting data and collecting data most of the worker updates become trivial - minutes rather than months. It becomes irrelevant if a worker is written in perl, python, C, java, scala, etc.

curryst 7y ago

I would argue that becoming "legacy" is akin to bit rot. Sure, it still runs, but everyone that knew how it worked has left the company, and it's written in a language that is no longer in vogue and will require specifically hiring people with that skill to maintain. As a counterpoint, I think we can both agree that writing production software in one of the toy languages that pops up on HN frontpage every day is a bad idea. Writing in a language that is old enough that it has become niche has many of the same issues. It doesn't really matter whether the software is poorly understood because the language is new enough to be niche or old enough to be niche; the outcome is the same.