7 ms·

I learned Perl in the late 90's and I still use Perl 5 all the time. The semiconductor industry is held together with thousands of lines of Tcl and Perl code.

I learned Perl in the late 90's and I still use Perl 5 all the time. The semiconductor industry is held together with thousands of lines of Tcl and Perl code. Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. Introducing a new language doesn't seem worth it.

dtech 6y ago
That's going to work right up until you all retire around the same time
- n3storm 6y ago
  LoL
- brokenkebab 6y ago
  There are loads of battle-tested well-working Perl code around, and its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. So no matter what is Perl's future in terms of evolution, or mindshare there will be Perl programmers until the code is retired, and its unlikely to happen anytime soon.
  - dtech 6y ago
    There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. [1] If your hypothesis would be true this wouldn't be the case, as there would always be enough smart devs to learn COBOL and keep working on them. [1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancient-computer-language-is-slowing-america-s-giant-stimulus https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
    - clipradiowallet 6y ago
      It's a pay problem. I don't mind learning some random COBOL codebase and maintaining it, but clients don't want to pay consulting rates over the long term, for what they view as "maintaining an old system".
    - nix23 6y ago
      Yeah, just imagine a part of the Goverment would say "hey we forgot to bring in new peoples and pay them right..sorry", instead of "we did nothing wrong, it's that bad unmaintainable Code-Base and that bad Language named Cobol, and the Mainframe is btw 15 years old" told over Zoom on a Windows10 Machine ;)
    - rst 6y ago
      It's not just COBOL, it's the whole OS environment -- which, for a lot of these old systems, involves legacy mainframe tech (z/OS) with its own peculiar jargon. Basic concepts like "file", "directory", and "disk drive" have different names, and subtly different relationships, and the closest thing to shell scripting is the notorious JCL, with a syntax derived from assembly language (back when writing applications in assembly was a common thing), and described more than once by the person most responsible for it (Fred Brooks) as "the worst computer programming language ever devised by anybody, anywhere". Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty: https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...
    - brokenkebab 6y ago
      It perfectly supports my hypothesis. Cobol is bloody 60+ old. It was in the category of “oh so old" languages in 80s already, and it took another 40 years to reach the point when its code became too old to support.
    - dragonwriter 6y ago
      > There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for. They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language. If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain. But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
      - xupybd 6y ago
        I worked with a great perl backend. Some of the best written perl I've seen, but I hate perl. If I never have to touch it again I'll be happy. I'm now working in .net and I love the tooling and how easy it is to use.
    - rory 6y ago
      Perl is far less exotic than COBOL when compared to modern languages that are still in heavy use. It looks kinda like C or PHP and feels kinda like Python or Ruby. I've never written COBOL but it looks almost as foreign to me as a punchcard.
      - rswail 6y ago
        Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION." I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
        rory 6y ago
        Yeah maybe a better phrasing is "Perl has more in common with languages still in heavy use" since it also has its own quirks. Interesting about the layout-- admittedly I know very little about COBOL or FORTRAN. I'm just reacting to scans of example code.
        raiph 6y ago
        > Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION." I disagree. "$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?) "@" is understandable for a 6 year old.[2] Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2] [1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable. [2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
    - gpvos 6y ago
      Relevant recent post and discussion: Why COBOL isn’t the problem, https://news.ycombinator.com/item?id=26475331 https://news.ycombinator.com/item?id=26475331
  - thatwasunusual 6y ago
    > its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. Short term? Probably. Long term? Probably not. At one point your _one_ Perl developer will disappear, and while you held onto that one person, the Perl language has faded even more into oblivion, making it literally _impossible_ for you to hire people to maintain your product.
    - dspillett 6y ago
      > Long term? Probably not. If companies are sensible and have learned from past issues, yes. But I live in the real world, so no! Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes. > to maintain your product. Often with Perl it isn't the end product that is the issue, that is more likely to have been ported to some other language/framework, but instead all that Perl is managing IT and project infrastructure.
      - thatwasunusual 6y ago
        >> Long term? Probably not. > If companies are sensible and have learned from past issues, yes. But I live in the real world, so no! In my world, more and more companies learns from past issues/failures. They also live in the same world as you do, which sees a decline in both number of Perl programmers and a decline in general usage of the language itself.[1][2][3] > Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes. That was 20 years ago. Plus, it's not a good thing that people are "pulled out of retirement" to fix things. [1] https://trends.google.com/trends/explore?date=2011-01-01%202020-12-31&q=%2Fm%2F05zrn https://trends.google.com/trends/explore?date=2011-01-01%202... [2] https://insights.stackoverflow.com/trends?tags=perl https://insights.stackoverflow.com/trends?tags=perl [3] https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/ https://www.statista.com/statistics/793628/worldwide-develop...
        edoceo 6y ago
        > In my world, more and more companies learns from past issues/failures. Welcome to earth! We don't do it that way here.
  - fatbird 6y ago
    The problem is that it's not just learning Perl, it's learning Perl and the monolithic app (or forest of microservices) at the same time; and if that one smart dev doesn't want to keep doing it, you keep repeating that learning curve with all the costs associated with it.
- iso1210 6y ago
  Just around 2038 as people go "what the hell does this perl code do" as the clock rolls over.
  - petre 6y ago
    It already supports 64 bit ints and relies on time_t and other lower level types. If these work in 2038 so will Perl.
    - bmn__ 6y ago
      https://perldoc.perl.org/perl5120delta#Y2038-compliance https://perldoc.perl.org/perl5120delta#Y2038-compliance
asicsp 6y ago
>The semiconductor industry is held together with thousands of lines of Tcl and Perl code That's where I learned Perl (along with getting familiar with Linux and Vim). I didn't have to use Tcl, but my team members had to. Based on our experience, we got a one-credit course started on these topics for our dept in college. These days they have moved on to Python though.
goto11 6y ago
Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?
- forgotmypw17 6y ago
  I started a new project in Perl a couple of years ago precisely because it has remained stable and without breaking changes for all this time. It's a feature, not a bug, that the language has remained stable and backwards compatible all this time. I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded. I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself. I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
  - tannhaeuser 6y ago
    TBH, Perl being frozen in time isn't by design but rather a result of the extremely long (15+ years?) cycle of releasing Perl 6/Raku. In its heyday, Perl used to introduce new features and sigills all the time in dot versions. Also, I don't think Perl can claim the moral high ground on stability when the languages Perl was supposed to replace, such as awk, are POSIX-standardized and have multiple interworking implementations, and Perl even shipped an aggressive awk-to-Perl converter (a2p). As a legacy of Perl, PCREs with capture groups and above-regular language features invading environments and especially web frameworks and JavaScript also are of dubious value because of the attack vectors they bring.
    - forgotmypw17 6y ago
      Fair points... But that's what has happened, and whatever the reasons, I am grateful for the blessings. Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
      - 6y ago
ptero 6y ago
> Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. You nailed it, but this cuts both ways: as the folks who used to do everything in Perl move out, the language fades. In the last few years I see that new tasks that would be done in perl several years ago are now done in python. I like perl, but I think its best days are over.
- tmountain 6y ago
  I also learned Perl in the 90s. I loved it at the time, as it was so much easier than writing C code to parse a config or do basic text manipulation (was working at an ISP). Hearing about the "future of Perl" feels a bit like pondering the future of VHS tapes. Perl exists, and as far as I'm concerned, it is a finished product. There are countless language options that have come onto the scene since it was in its heyday, and that leaves me wondering what the goals are regarding reinventing or reimagining Perl. Who is the target audience? What is the target problem space, and why can't those issues be tackled within the modern language ecosystem? I'm not knocking the effort or initiative. I'm genuinely curious.
  - jjav 6y ago
    The problem space is string handling, particularly regex use. There is no other language (that I know of, certainly no mainstream language) where regexes are the first class citizen they are in perl. In every other language regex handling varies from a bit of a chore to downright painful, where in perl it is natural. So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
    - indocomsoft 6y ago
      What about Ruby?
snicker7 6y ago
I maintained a financial data pipeline written almost entirely in Perl. Literally thousands of scripts accumulated over decades.
- racl101 6y ago
  Sounds like a good way to stay employed ha ha.
thatwasunusual 6y ago
> The semiconductor industry is held together with thousands of lines of Tcl and Perl code. Is that the reason why there's a shortage of new NVidia cards? /s

dtech 6y ago

That's going to work right up until you all retire around the same time

n3storm 6y ago
LoL
brokenkebab 6y ago
There are loads of battle-tested well-working Perl code around, and its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. So no matter what is Perl's future in terms of evolution, or mindshare there will be Perl programmers until the code is retired, and its unlikely to happen anytime soon.
- dtech 6y ago
  There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. [1] If your hypothesis would be true this wouldn't be the case, as there would always be enough smart devs to learn COBOL and keep working on them. [1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancient-computer-language-is-slowing-america-s-giant-stimulus https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
  - clipradiowallet 6y ago
    It's a pay problem. I don't mind learning some random COBOL codebase and maintaining it, but clients don't want to pay consulting rates over the long term, for what they view as "maintaining an old system".
  - nix23 6y ago
    Yeah, just imagine a part of the Goverment would say "hey we forgot to bring in new peoples and pay them right..sorry", instead of "we did nothing wrong, it's that bad unmaintainable Code-Base and that bad Language named Cobol, and the Mainframe is btw 15 years old" told over Zoom on a Windows10 Machine ;)
  - rst 6y ago
    It's not just COBOL, it's the whole OS environment -- which, for a lot of these old systems, involves legacy mainframe tech (z/OS) with its own peculiar jargon. Basic concepts like "file", "directory", and "disk drive" have different names, and subtly different relationships, and the closest thing to shell scripting is the notorious JCL, with a syntax derived from assembly language (back when writing applications in assembly was a common thing), and described more than once by the person most responsible for it (Fred Brooks) as "the worst computer programming language ever devised by anybody, anywhere". Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty: https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...
  - brokenkebab 6y ago
    It perfectly supports my hypothesis. Cobol is bloody 60+ old. It was in the category of “oh so old" languages in 80s already, and it took another 40 years to reach the point when its code became too old to support.
  - dragonwriter 6y ago
    > There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for. They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language. If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain. But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
    - xupybd 6y ago
      I worked with a great perl backend. Some of the best written perl I've seen, but I hate perl. If I never have to touch it again I'll be happy. I'm now working in .net and I love the tooling and how easy it is to use.
  - rory 6y ago
    Perl is far less exotic than COBOL when compared to modern languages that are still in heavy use. It looks kinda like C or PHP and feels kinda like Python or Ruby. I've never written COBOL but it looks almost as foreign to me as a punchcard.
    - rswail 6y ago
      Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION." I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
      - rory 6y ago
        Yeah maybe a better phrasing is "Perl has more in common with languages still in heavy use" since it also has its own quirks. Interesting about the layout-- admittedly I know very little about COBOL or FORTRAN. I'm just reacting to scans of example code.
      - raiph 6y ago
        > Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION." I disagree. "$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?) "@" is understandable for a 6 year old.[2] Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2] [1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable. [2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
  - gpvos 6y ago
    Relevant recent post and discussion: Why COBOL isn’t the problem, https://news.ycombinator.com/item?id=26475331 https://news.ycombinator.com/item?id=26475331
- thatwasunusual 6y ago
  > its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. Short term? Probably. Long term? Probably not. At one point your _one_ Perl developer will disappear, and while you held onto that one person, the Perl language has faded even more into oblivion, making it literally _impossible_ for you to hire people to maintain your product.
  - dspillett 6y ago
    > Long term? Probably not. If companies are sensible and have learned from past issues, yes. But I live in the real world, so no! Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes. > to maintain your product. Often with Perl it isn't the end product that is the issue, that is more likely to have been ported to some other language/framework, but instead all that Perl is managing IT and project infrastructure.
    - thatwasunusual 6y ago
      >> Long term? Probably not. > If companies are sensible and have learned from past issues, yes. But I live in the real world, so no! In my world, more and more companies learns from past issues/failures. They also live in the same world as you do, which sees a decline in both number of Perl programmers and a decline in general usage of the language itself.[1][2][3] > Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes. That was 20 years ago. Plus, it's not a good thing that people are "pulled out of retirement" to fix things. [1] https://trends.google.com/trends/explore?date=2011-01-01%202020-12-31&q=%2Fm%2F05zrn https://trends.google.com/trends/explore?date=2011-01-01%202... [2] https://insights.stackoverflow.com/trends?tags=perl https://insights.stackoverflow.com/trends?tags=perl [3] https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/ https://www.statista.com/statistics/793628/worldwide-develop...
      - edoceo 6y ago
        > In my world, more and more companies learns from past issues/failures. Welcome to earth! We don't do it that way here.
- fatbird 6y ago
  The problem is that it's not just learning Perl, it's learning Perl and the monolithic app (or forest of microservices) at the same time; and if that one smart dev doesn't want to keep doing it, you keep repeating that learning curve with all the costs associated with it.
iso1210 6y ago
Just around 2038 as people go "what the hell does this perl code do" as the clock rolls over.
- petre 6y ago
  It already supports 64 bit ints and relies on time_t and other lower level types. If these work in 2038 so will Perl.
  - bmn__ 6y ago
    https://perldoc.perl.org/perl5120delta#Y2038-compliance https://perldoc.perl.org/perl5120delta#Y2038-compliance

asicsp 6y ago

>The semiconductor industry is held together with thousands of lines of Tcl and Perl code That's where I learned Perl (along with getting familiar with Linux and Vim). I didn't have to use Tcl, but my team members had to. Based on our experience, we got a one-credit course started on these topics for our dept in college. These days they have moved on to Python though.

goto11 6y ago

Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?

forgotmypw17 6y ago
I started a new project in Perl a couple of years ago precisely because it has remained stable and without breaking changes for all this time. It's a feature, not a bug, that the language has remained stable and backwards compatible all this time. I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded. I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself. I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
- tannhaeuser 6y ago
  TBH, Perl being frozen in time isn't by design but rather a result of the extremely long (15+ years?) cycle of releasing Perl 6/Raku. In its heyday, Perl used to introduce new features and sigills all the time in dot versions. Also, I don't think Perl can claim the moral high ground on stability when the languages Perl was supposed to replace, such as awk, are POSIX-standardized and have multiple interworking implementations, and Perl even shipped an aggressive awk-to-Perl converter (a2p). As a legacy of Perl, PCREs with capture groups and above-regular language features invading environments and especially web frameworks and JavaScript also are of dubious value because of the attack vectors they bring.
  - forgotmypw17 6y ago
    Fair points... But that's what has happened, and whatever the reasons, I am grateful for the blessings. Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
    - 6y ago

ptero 6y ago

> Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. You nailed it, but this cuts both ways: as the folks who used to do everything in Perl move out, the language fades. In the last few years I see that new tasks that would be done in perl several years ago are now done in python. I like perl, but I think its best days are over.

tmountain 6y ago
I also learned Perl in the 90s. I loved it at the time, as it was so much easier than writing C code to parse a config or do basic text manipulation (was working at an ISP). Hearing about the "future of Perl" feels a bit like pondering the future of VHS tapes. Perl exists, and as far as I'm concerned, it is a finished product. There are countless language options that have come onto the scene since it was in its heyday, and that leaves me wondering what the goals are regarding reinventing or reimagining Perl. Who is the target audience? What is the target problem space, and why can't those issues be tackled within the modern language ecosystem? I'm not knocking the effort or initiative. I'm genuinely curious.
- jjav 6y ago
  The problem space is string handling, particularly regex use. There is no other language (that I know of, certainly no mainstream language) where regexes are the first class citizen they are in perl. In every other language regex handling varies from a bit of a chore to downright painful, where in perl it is natural. So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
  - indocomsoft 6y ago
    What about Ruby?

snicker7 6y ago

I maintained a financial data pipeline written almost entirely in Perl. Literally thousands of scripts accumulated over decades.

racl101 6y ago
Sounds like a good way to stay employed ha ha.

thatwasunusual 6y ago

> The semiconductor industry is held together with thousands of lines of Tcl and Perl code. Is that the reason why there's a shortage of new NVidia cards? /s