6 ms·

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 t

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.

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.