9 ms·

Should Perl die gracefully?

40 points by mjgardner 5y ago

bombcar 5y ago
If your users are saying "stop messing with the language, we're no longer developing in it" you may want to consider why. There's a reason Linus does his hardest to avoid ever changing the user-facing kernel APIs (never break userspace). When you're a young language (Rust) you can get away with breaking API changes and your users will go along with it (often because they're asking for features they need to use the language) but at some point you cross the line where there's more code written than still to write.
- nynx 5y ago
  Sort of unrelated, but Rust doesn't make breaking changes. The language is fully backwards compatible.
  - leetrout 5y ago
    Is this due to features being available as macros and such?
    - CodesInChaos 5y ago
      For syntax level changes, "editions" allow libraries to opt into the new language version while keeping compatibility with old libraries. For most other issues it's simply accepting the suboptimal choices made in the past.
  - gmfawcett 5y ago
    I have some ten-year-old Rust code that would disagree with you. :) [edit -- and yes, it's pre-1.0 code. Not trying to be sneaky, just trying to clarify that the backwards-compatibility guarantee only goes back to a reasonable point in time.]
    - nynx 5y ago
      That's some impressively old rust code — from long before the initial release of the language!
      - freedomben 5y ago
        Might we say that their code has rusted?
        gmfawcett 5y ago
        Hahah, that is definitely true. :)
      - deaddodo 5y ago
        To be fair, pre-1.0 Rust was already heavily hyped and available. It's not hard to find plenty of projects from that time.
    - lilyball 5y ago
      Rust 1.0 came out 6 years ago. There’s no need to sow confusion by referring to pre-1.0 code here.
      - LeifCarrotson 5y ago
        That's a major version, yes, but not necessarily sowing confusion. Users have needs that often last longer than 6 years. I got a call last week to update a machine that's running VB 4 code from the mid-90s. It's a spot welder; the casting and transformers are from the 1940s, but the weld controller speaks RS-232 and is from the late 80s. I feel safe assuming the machine will still be in use long after I'm dead. We did a quick update with the original source code to fix a glaring bug that a new operator happened across, but they would like to add a simple database integration feature. The interface simple enough that the update will be a nearly complete rewrite; we'll retain the .ini settings files and custom CSV file format. However, we will be choosing a platform that should last as long as the original. That platform will not be some new hot JS framework that's going to be marked end-of-life before the warranty is up. Not everyone is on a 2-year treadmill!
- mamcx 5y ago
  I think a language must break moving forward. The more something is afraid of change, the more it stay like that AND DRAG EVERYTHING ELSE. I live in the enterprise software sector, and you don't know much problem it cause this. Because X is old and not updated, in must(? who knows but nobody dare to check) run in OLD OS, with OLD rmdbs, with OLD runtimes with OLD ssl libraries, etc, etc. So, you come along with a neat solution to their problems, and you face the fact you must "downgrade" everything to compile/ship: Your lang, drivers, third-party deps, etc. And then you must hunt down the docs for all that! THIS is the reason a lot of companies use old internet explorer/old windows/old linux. Because X not dare to break! --- The silver line here is the advent of virtual machines and now docker. Moving forward, run in docker (or similar) is the ay to go for isolated that pesky dips that live in the old era. But, sadly, docker don't run in that OS, because that pesky OLD deps need it!
mrRandomGuy 5y ago
Perl _has_ died gracefully.
- ivanhoe 5y ago
  Hell, not even Fortran and Cobol are really dead, and Perl is way more popular still. You still have millions of perl scripts running daily, many of them doing some really critical stuff. It's not mainstream language anymore as it used to be once upon the time, but falling from spotlights isn't the same as dying (which Cobol demonstrates successfully again and again every few decades).
  - bombcar 5y ago
    The key is it's being used but the scripts are more and more not maintained - and if you want users to not stay on outdated versions you have to consider that. Many security patches will be avoided if upgrading breaks stuff. Like Raymond Chen says - if upgrading Windows breaks your software, you will blame Microsoft even if the software is where the error is.
    - swiley 5y ago
      Both scripts and perl itself are being maintained. It's definitely not dead and pretty unlikely to die any time soon.
      - dale_glass 5y ago
        The big issue is with CPAN. An increasing risk of using Perl is that your dependencies may be rotting without you noticing it. And this may happen in multiple ways: * Modules that use some arcane syntax that's being deprecated. * Modules that link against libraries that are still being developed * Web APIs that are still evolving. Perl's great strength has always been CPAN, and with its decreasing popularity that's now becoming a weakness. For instance, Amazon::S3 was last released in 2009. AWS::S3 was last released in 2019. Net::Amazon::S3 seems alive and well, but the "++ed by 6 PAUSE users" isn't very comforting. I'm personally increasingly switching away from Perl, because I've been noticing the concerning amount of familiar modules whose last release was several years ago, which has bugs that went completely unacknowledged on the bug tracker for years, and the realization that there are big, complex modules that may be depending on some random person in Nebraska. This is of course not a new issue, but it's particularly acute when an ecosystem is no longer "sexy" and people start moving on to greener pastures.
deleted 5y ago
[deleted]
jamal-kumar 5y ago
I still find perl to be pretty sweet for handling old data formats. Need to extract something out of an old foxpro DBF file? Perl has some great tools for that. Have a collection of excel files with the formats ~MIXED TOGETHER~ between xlsx and xls, and don't want to deal with using two seperate libraries in python or whatever? Perl is pretty sweet for that, handles both formats transparently -- I think they even have it as the example on their front page. I had asked to write something in python at one job and my boss was like no, the call stack gets way too big and it uses too much memory, and you're installing an interpreter which may introduce security problems. Write it in Perl, it's included in the OS. I really wonder how correct he was on that performance stuff but it wasn't an unpleasant experience given my skill level in that language at the time. I think perl's major weak point is that it's kind of hard to read if you don't know it.
- noisy_boy 5y ago
  Having written lots of Perl and Python, Perl just _felt_ fast (I don't have benchmarks to back this up). Also agree on the included in OS point (when I started coding in Perl, it came pre-installed on Sun Solaris; I do remember seeing some old version of Python too but by then we already had written a bunch of Perl).
  - hedora 5y ago
    Global variables in python are (used to be?) about 10x slower than variables in a scope. I gave up on python for other reasons (breaking changes every few months) before someone pointed that out to me. Anyway, for me, that was why Python “felt” slower than Perl.
makecheck 5y ago
This is just one case of the chain of “logic” so many people seem to make with software, for some reason: - I got your code for free - I set up Really Important Things using it - I have contributed nothing to you, for years now - I have also invested nothing in maintaining my Really Important Things (e.g. it is no one’s job at the company) - How dare you change anything!!
- deleted 5y ago
  [deleted]
- ivanhoe 5y ago
  Well, unless Larry Wall suddenly decides to make those breaking changes this really doesn't apply to big community driven projects like Perl - they don't belong to any one group of developers, so neither group can decide to break them as they wish. You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. Even more importantly, legacy projects are the ABSOLUTE majority of Perl projects left alive, so breaking them would be even bigger screw up than the Perl 6 was. BTW, no one says that language shouldn't be improved - that's a problem that can be very simply avoided with proper versioning. Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files, why not just help efforts on making Perl 7 a reality finally? Perl 5 will then then be free to focus on supporting the old projects and fixing bugs, while Perl 7 can add whatever they wish without worrying of old stuff...
  - bombcar 5y ago
    An example is the Python 2/3 debacle - it took forever and still isn't complete (and now there are documents on how to install Python 2 to run older software).
  - weare138 5y ago
    >You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. But how long can someone reasonably expect newer releases to support legacy code? It doesn't make sense to hold back the development of the entire language just to support software that's 20+ years old. >Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files Because it make it harder for people to learn modern Perl when you have to just through hoops to enable features people expect in a modern language. It would make more sense to have pragmas to disable features for backwards compatibility. Or like the article mentions, just use an older Perl distribution. If your codebase is really that old there's really not much reason to use the latest version of Perl.
acdha 5y ago
Posts like this are really hitting a key social challenge for open source in general: a large fraction of complaints like this come from companies which derive commercial value from projects like Perl but often do not contribute to maintenance. There's an easy criticism that these companies are basically freeloading, and there's definitely some truth to that but I think it also touches on the difficulties of doing so: most companies aren't set up to make small donations efficiently and it's hard to say which fraction of the business value would be allocated between Perl and the hundreds of CPAN modules they're likely using. Hiring developers can help in the sense that they'll probably cover many of the needs but that runs into a problematic dynamic where companies contribute things they need but not contributing to unrelated maintenance, which can actually increase the amount of labor on the open source team being asked to review and merge their contributions if that doesn't remove some of the other work. One argument is that Red Hat is a good compromise for many companies: your accountants can easily write a check for RHEL & support and they employ hundreds of people who contribute to a wide range of projects. Services like GitHub Sponsors are another vision for that but I don't think we've hit a good balance which doesn't result in a major project getting resources while a lot of smaller pieces languish. Umbrella groups like the Django Software Foundation are trying to help with that but I think that's still a work in progress.
- bachmeier 5y ago
  I've made the point repeatedly over the years that open source projects have to sell something if they want financial support. In the case of Perl, maybe it's a particular implementation that comes with printed documentation. "Download the stuff you want to use and then make a donation of arbitrary size if you feel like it" isn't going to work. The RHEL model won't work for most projects, because Red Hat has traditionally sold support services. Slackware would be a better example. You used to be able to buy CDs with the new release if you wanted to support the project.
  - bombcar 5y ago
    One of the key things RedHat sells is "your code doesn't need to change for X years" - but a side effect of this is you suddenly have a BUNCH of changes that need to be made every X years as new distributions come out. Even though Microsoft deprecates versions of Windows, they often keep supporting the APIs used for insanely long periods of time. Open Source software doesn't really have the incentive to do this unless "forced" by leadership or a standards body (and even that isn't entirely well enforced, how deviated from Posix are we now). Java may be similar to a cross between these - as old versions of the JDK continue to be supported and developed, but I assume there's money flowing somewhere to do so.
dave_aiello 5y ago
I have a few critical system integration scripts written in Perl. I've felt for a while that silent failure is a serious possibility when Linux distributions change bundled Perl versions with little or no discussion. The medium-term answer for me is probably to learn Python well enough to port my code to it.
- teddyh 5y ago
  For a Perl-to-Python journey, the first thing you should probably read is this: https://www.linuxjournal.com/article/3882 https://www.linuxjournal.com/article/3882
- Grinnz 5y ago
  Curious what makes you think Python will be less susceptible to this, after the whole 2to3 debacle? I'll note that Perl just went through a year or so of painful argument to rediscover that "Perl should stay Perl", so I'd be more confident in that.
  - hedora 5y ago
    This. Perl at least attempts to maintain backwards compatibility. Python libraries and the interpreter actively break old code all the time. Also, Python is at least as bad as Perl about breaking silently. If you care about maintaining a codebase over time, pick anything that has static types. I’ve found Go to be a reasonable python replacement, though I haven’t found either python or go to be a reasonable perl replacement.
  - dave_aiello 5y ago
    I don't know. I felt that Python 3 was an attempt to route around problems in Python 2 that couldn't be easily fixed. I don't have much invested in Python at the moment. I would be more aware of and concerned about Python issues if I had larger scripts written in it that I need to maintain. I have used Perl 5 long enough to know that it is a mature language. I'm concerned about the integrity of CPAN and individual modules' abilities to interoperate with the versions of Linux that I deploy in production.
- 5y ago
sys_64738 5y ago
I use it for regex on the WSL shell. Another win for M$!
enriquto 5y ago
should Python die, also? is you buy a new macbook today, the base system comes with a few hundred perl scripts and a few dozen python scripts. Please, dot believe me; just file|grep your path and check it yourselves.
- jerf 5y ago
  Personally I would say all the dynamic scripting languages, while they shouldn't "die", should stop focusing on adding new features and focus on the other things that will enhance the value of the language as it exists. This isn't criticism of those languages; it's a compliment! They've all hit maturity, in my opinion. That's a good thing. But I think their developer communities still sometimes don't act like that's the case, to their detriment.
JJMcJ 5y ago
The Perl developers have actually done an excellent job of maintaining compatibility. Old Perl programs can often run without any changes.
hcduytWW 5y ago
I'm John Williams from the United State of America, i was scammed by two hacker's while trying to look for a recovering agent and Mobile spy access to my girlfriend's iPhone 12 pro Max. I lost a lot of money online to fake broker's and as well fake hacker's who I came across in the first place when I searched on google engine. I was on trust pilot trying to see some review when i came across (wizardharry@programmer.net) i quickly contact him but was nervous because i have had a lot of bad experience over the internet, it was hard to believe him but i put it to try anyway, then i discover he is a legend and honest hacker, both my lost funds where recovered and i got more than i lose, right now i have mobile spy remote access to my girlfriend phone without her knowledge. All thanks to wizard Harry. You can also WhatsApp him (+1-807-808-6168)

40 points by mjgardner 5y ago

If your users are saying "stop messing with the language, we're no longer developing in it" you may want to consider why. There's a reason Linus does his hardest to avoid ever changing the user-facing kernel APIs (never break userspace). When you're a young language (Rust) you can get away with breaking API changes and your users will go along with it (often because they're asking for features they need to use the language) but at some point you cross the line where there's more code written than still to write.

nynx 5y ago
Sort of unrelated, but Rust doesn't make breaking changes. The language is fully backwards compatible.
- leetrout 5y ago
  Is this due to features being available as macros and such?
  - CodesInChaos 5y ago
    For syntax level changes, "editions" allow libraries to opt into the new language version while keeping compatibility with old libraries. For most other issues it's simply accepting the suboptimal choices made in the past.
- gmfawcett 5y ago
  I have some ten-year-old Rust code that would disagree with you. :) [edit -- and yes, it's pre-1.0 code. Not trying to be sneaky, just trying to clarify that the backwards-compatibility guarantee only goes back to a reasonable point in time.]
  - nynx 5y ago
    That's some impressively old rust code — from long before the initial release of the language!
    - freedomben 5y ago
      Might we say that their code has rusted?
      - gmfawcett 5y ago
        Hahah, that is definitely true. :)
    - deaddodo 5y ago
      To be fair, pre-1.0 Rust was already heavily hyped and available. It's not hard to find plenty of projects from that time.
  - lilyball 5y ago
    Rust 1.0 came out 6 years ago. There’s no need to sow confusion by referring to pre-1.0 code here.
    - LeifCarrotson 5y ago
      That's a major version, yes, but not necessarily sowing confusion. Users have needs that often last longer than 6 years. I got a call last week to update a machine that's running VB 4 code from the mid-90s. It's a spot welder; the casting and transformers are from the 1940s, but the weld controller speaks RS-232 and is from the late 80s. I feel safe assuming the machine will still be in use long after I'm dead. We did a quick update with the original source code to fix a glaring bug that a new operator happened across, but they would like to add a simple database integration feature. The interface simple enough that the update will be a nearly complete rewrite; we'll retain the .ini settings files and custom CSV file format. However, we will be choosing a platform that should last as long as the original. That platform will not be some new hot JS framework that's going to be marked end-of-life before the warranty is up. Not everyone is on a 2-year treadmill!
mamcx 5y ago
I think a language must break moving forward. The more something is afraid of change, the more it stay like that AND DRAG EVERYTHING ELSE. I live in the enterprise software sector, and you don't know much problem it cause this. Because X is old and not updated, in must(? who knows but nobody dare to check) run in OLD OS, with OLD rmdbs, with OLD runtimes with OLD ssl libraries, etc, etc. So, you come along with a neat solution to their problems, and you face the fact you must "downgrade" everything to compile/ship: Your lang, drivers, third-party deps, etc. And then you must hunt down the docs for all that! THIS is the reason a lot of companies use old internet explorer/old windows/old linux. Because X not dare to break! --- The silver line here is the advent of virtual machines and now docker. Moving forward, run in docker (or similar) is the ay to go for isolated that pesky dips that live in the old era. But, sadly, docker don't run in that OS, because that pesky OLD deps need it!

mrRandomGuy 5y ago

Perl _has_ died gracefully.

ivanhoe 5y ago
Hell, not even Fortran and Cobol are really dead, and Perl is way more popular still. You still have millions of perl scripts running daily, many of them doing some really critical stuff. It's not mainstream language anymore as it used to be once upon the time, but falling from spotlights isn't the same as dying (which Cobol demonstrates successfully again and again every few decades).
- bombcar 5y ago
  The key is it's being used but the scripts are more and more not maintained - and if you want users to not stay on outdated versions you have to consider that. Many security patches will be avoided if upgrading breaks stuff. Like Raymond Chen says - if upgrading Windows breaks your software, you will blame Microsoft even if the software is where the error is.
  - swiley 5y ago
    Both scripts and perl itself are being maintained. It's definitely not dead and pretty unlikely to die any time soon.
    - dale_glass 5y ago
      The big issue is with CPAN. An increasing risk of using Perl is that your dependencies may be rotting without you noticing it. And this may happen in multiple ways: * Modules that use some arcane syntax that's being deprecated. * Modules that link against libraries that are still being developed * Web APIs that are still evolving. Perl's great strength has always been CPAN, and with its decreasing popularity that's now becoming a weakness. For instance, Amazon::S3 was last released in 2009. AWS::S3 was last released in 2019. Net::Amazon::S3 seems alive and well, but the "++ed by 6 PAUSE users" isn't very comforting. I'm personally increasingly switching away from Perl, because I've been noticing the concerning amount of familiar modules whose last release was several years ago, which has bugs that went completely unacknowledged on the bug tracker for years, and the realization that there are big, complex modules that may be depending on some random person in Nebraska. This is of course not a new issue, but it's particularly acute when an ecosystem is no longer "sexy" and people start moving on to greener pastures.

deleted 5y ago

[deleted]

jamal-kumar 5y ago

I still find perl to be pretty sweet for handling old data formats. Need to extract something out of an old foxpro DBF file? Perl has some great tools for that. Have a collection of excel files with the formats ~MIXED TOGETHER~ between xlsx and xls, and don't want to deal with using two seperate libraries in python or whatever? Perl is pretty sweet for that, handles both formats transparently -- I think they even have it as the example on their front page. I had asked to write something in python at one job and my boss was like no, the call stack gets way too big and it uses too much memory, and you're installing an interpreter which may introduce security problems. Write it in Perl, it's included in the OS. I really wonder how correct he was on that performance stuff but it wasn't an unpleasant experience given my skill level in that language at the time. I think perl's major weak point is that it's kind of hard to read if you don't know it.

noisy_boy 5y ago
Having written lots of Perl and Python, Perl just _felt_ fast (I don't have benchmarks to back this up). Also agree on the included in OS point (when I started coding in Perl, it came pre-installed on Sun Solaris; I do remember seeing some old version of Python too but by then we already had written a bunch of Perl).
- hedora 5y ago
  Global variables in python are (used to be?) about 10x slower than variables in a scope. I gave up on python for other reasons (breaking changes every few months) before someone pointed that out to me. Anyway, for me, that was why Python “felt” slower than Perl.

makecheck 5y ago

This is just one case of the chain of “logic” so many people seem to make with software, for some reason: - I got your code for free - I set up Really Important Things using it - I have contributed nothing to you, for years now - I have also invested nothing in maintaining my Really Important Things (e.g. it is no one’s job at the company) - How dare you change anything!!

deleted 5y ago
[deleted]
ivanhoe 5y ago
Well, unless Larry Wall suddenly decides to make those breaking changes this really doesn't apply to big community driven projects like Perl - they don't belong to any one group of developers, so neither group can decide to break them as they wish. You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. Even more importantly, legacy projects are the ABSOLUTE majority of Perl projects left alive, so breaking them would be even bigger screw up than the Perl 6 was. BTW, no one says that language shouldn't be improved - that's a problem that can be very simply avoided with proper versioning. Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files, why not just help efforts on making Perl 7 a reality finally? Perl 5 will then then be free to focus on supporting the old projects and fixing bugs, while Perl 7 can add whatever they wish without worrying of old stuff...
- bombcar 5y ago
  An example is the Python 2/3 debacle - it took forever and still isn't complete (and now there are documents on how to install Python 2 to run older software).
- weare138 5y ago
  >You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. But how long can someone reasonably expect newer releases to support legacy code? It doesn't make sense to hold back the development of the entire language just to support software that's 20+ years old. >Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files Because it make it harder for people to learn modern Perl when you have to just through hoops to enable features people expect in a modern language. It would make more sense to have pragmas to disable features for backwards compatibility. Or like the article mentions, just use an older Perl distribution. If your codebase is really that old there's really not much reason to use the latest version of Perl.

acdha 5y ago

Posts like this are really hitting a key social challenge for open source in general: a large fraction of complaints like this come from companies which derive commercial value from projects like Perl but often do not contribute to maintenance. There's an easy criticism that these companies are basically freeloading, and there's definitely some truth to that but I think it also touches on the difficulties of doing so: most companies aren't set up to make small donations efficiently and it's hard to say which fraction of the business value would be allocated between Perl and the hundreds of CPAN modules they're likely using. Hiring developers can help in the sense that they'll probably cover many of the needs but that runs into a problematic dynamic where companies contribute things they need but not contributing to unrelated maintenance, which can actually increase the amount of labor on the open source team being asked to review and merge their contributions if that doesn't remove some of the other work. One argument is that Red Hat is a good compromise for many companies: your accountants can easily write a check for RHEL & support and they employ hundreds of people who contribute to a wide range of projects. Services like GitHub Sponsors are another vision for that but I don't think we've hit a good balance which doesn't result in a major project getting resources while a lot of smaller pieces languish. Umbrella groups like the Django Software Foundation are trying to help with that but I think that's still a work in progress.

bachmeier 5y ago
I've made the point repeatedly over the years that open source projects have to sell something if they want financial support. In the case of Perl, maybe it's a particular implementation that comes with printed documentation. "Download the stuff you want to use and then make a donation of arbitrary size if you feel like it" isn't going to work. The RHEL model won't work for most projects, because Red Hat has traditionally sold support services. Slackware would be a better example. You used to be able to buy CDs with the new release if you wanted to support the project.
- bombcar 5y ago
  One of the key things RedHat sells is "your code doesn't need to change for X years" - but a side effect of this is you suddenly have a BUNCH of changes that need to be made every X years as new distributions come out. Even though Microsoft deprecates versions of Windows, they often keep supporting the APIs used for insanely long periods of time. Open Source software doesn't really have the incentive to do this unless "forced" by leadership or a standards body (and even that isn't entirely well enforced, how deviated from Posix are we now). Java may be similar to a cross between these - as old versions of the JDK continue to be supported and developed, but I assume there's money flowing somewhere to do so.

dave_aiello 5y ago

I have a few critical system integration scripts written in Perl. I've felt for a while that silent failure is a serious possibility when Linux distributions change bundled Perl versions with little or no discussion. The medium-term answer for me is probably to learn Python well enough to port my code to it.

teddyh 5y ago
For a Perl-to-Python journey, the first thing you should probably read is this: https://www.linuxjournal.com/article/3882 https://www.linuxjournal.com/article/3882
Grinnz 5y ago
Curious what makes you think Python will be less susceptible to this, after the whole 2to3 debacle? I'll note that Perl just went through a year or so of painful argument to rediscover that "Perl should stay Perl", so I'd be more confident in that.
- hedora 5y ago
  This. Perl at least attempts to maintain backwards compatibility. Python libraries and the interpreter actively break old code all the time. Also, Python is at least as bad as Perl about breaking silently. If you care about maintaining a codebase over time, pick anything that has static types. I’ve found Go to be a reasonable python replacement, though I haven’t found either python or go to be a reasonable perl replacement.
- dave_aiello 5y ago
  I don't know. I felt that Python 3 was an attempt to route around problems in Python 2 that couldn't be easily fixed. I don't have much invested in Python at the moment. I would be more aware of and concerned about Python issues if I had larger scripts written in it that I need to maintain. I have used Perl 5 long enough to know that it is a mature language. I'm concerned about the integrity of CPAN and individual modules' abilities to interoperate with the versions of Linux that I deploy in production.
5y ago

sys_64738 5y ago

I use it for regex on the WSL shell. Another win for M$!

enriquto 5y ago

should Python die, also? is you buy a new macbook today, the base system comes with a few hundred perl scripts and a few dozen python scripts. Please, dot believe me; just file|grep your path and check it yourselves.

jerf 5y ago
Personally I would say all the dynamic scripting languages, while they shouldn't "die", should stop focusing on adding new features and focus on the other things that will enhance the value of the language as it exists. This isn't criticism of those languages; it's a compliment! They've all hit maturity, in my opinion. That's a good thing. But I think their developer communities still sometimes don't act like that's the case, to their detriment.

JJMcJ 5y ago

The Perl developers have actually done an excellent job of maintaining compatibility. Old Perl programs can often run without any changes.

hcduytWW 5y ago

I'm John Williams from the United State of America, i was scammed by two hacker's while trying to look for a recovering agent and Mobile spy access to my girlfriend's iPhone 12 pro Max. I lost a lot of money online to fake broker's and as well fake hacker's who I came across in the first place when I searched on google engine. I was on trust pilot trying to see some review when i came across (wizardharry@programmer.net) i quickly contact him but was nervous because i have had a lot of bad experience over the internet, it was hard to believe him but i put it to try anyway, then i discover he is a legend and honest hacker, both my lost funds where recovered and i got more than i lose, right now i have mobile spy remote access to my girlfriend phone without her knowledge. All thanks to wizard Harry. You can also WhatsApp him (+1-807-808-6168)