Nobody in the department understands Perl or wants to.
And that is the problem.
I don't know how bad that code is - a lot of Perl code from that period is not good - but learning enough Perl to have a shot at it literally should take a competent developer a few minutes if you had someone explain it to you.
You might find the language weird. $ means "the". @ means "these". % indicates you're building a lookup. Which you then access with braces. So %foo is a lookup. And $foo{$bar} should be read "the foo of the bar...".
Early Perl 5 means it probably doesn't use references or objects. You do use regular expressions. While regular expressions are built into Perl in a way that makes them easy to use, Perl-like regular expressions are in pretty much every language. So the effort you need to use them is directly portable to Python, JavaScript, Java, etc, etc, etc.
Fluency takes a lot longer. But getting to the point of "I can puzzle my way through a language I don't know well" should be doable very quickly. And it is a skill that every developer should build. Because I guarantee that whatever language and toolset you are using now, you'll need to be able to switch at some point in your career. And practicing in advance will help you. Plus being the person who can puzzle out old ganky code in another language lets you be a hero in fun ways!
> the business (read: product owner) has deemed it unimportant to update or understand,
That's the problem. It's not on a random person in the department to spend their own time trying to solve a problem the business doesn't want invest time or money into solving. I don't see you offering to do this for free, so don't claim that's a problem for others.
I've been around the block enough to read between the lines on this one.
All of the talk about how old and bad the language is, and how nobody wants to learn it is tech speak for, "We can't support it as is, we need a rewrite!" Anyone who has been near tech for a long time knows "rewrite" means "tech is going to break it for unclear reasons and uncertain gain, and in a few years will want to rewrite it again. Tech people always underestimate the cost and risk of a rewrite, and also overestimate the benefits.
Business is not being stupid in saying that tech can't rewrite the software. The software is there, works, and is being relied on. Tech should figure out how to support it without a risky rewrite. Don't stand on, "We don't want to learn Perl." Learn how to be a polyglot. At least when it comes to reading. And to the extent that tech understands the value of being prepared, tech should prepare in advance. And figuring out how to read the code is most of that battle.
Now you accuse me of not offering to do this for free. But in fact I offered the best tip I could for a non-Perl programmer who is trying to puzzle their way through an early Perl 5 script. Given that I'm an internationally recognized expert in Perl, that tip probably does more good than you realize. Learning how to navigate legacy code in a legacy language is a learnable skill. And you learn it by trying, then finding you can. And no matter how much you don't wish to learn any particular legacy language, having the confidence to know you can is valuable.
> All of the talk about how old and bad the language is, and how nobody wants to learn it is tech speak for, "We can't support it as is, we need a rewrite!" Anyone who has been near tech for a long time knows "rewrite" means "tech is going to break it for unclear reasons and uncertain gain, and in a few years will want to rewrite it again. Tech people always underestimate the cost and risk of a rewrite, and also overestimate the benefits.
No, it really isn't. I'm happy to learn a new language. The reason is correctly stated by a sibling post here (WesolyKubeczek).
That we've been able to containerise it has limited a lot of the risk, and any upstream issues we have going forward we should be able to write some middleware to sit between it and transform the data into the format we need. We can extend the container to proxy any requests from the ancient application to the new middleware. We have a strategy, the product owner is happy with that, but we've outlined that maybe the solution won't work as we think, there are always unknown unknowns...
The issue is that if a problem does arise, it will be immediate and the effects will be there for as long as it takes to get a fix up and running, which could be weeks to who knows how long. That's a real risk in my eyes, but it wasn't to our product owner.
It will affect a lot of people, it's a pretty widely used service! It's entertainment, so people won't die if it fails.
The risk was deemed low enough by the product owner that we can just leave it in a container until it's finally sunsetted in 5-10 years (or so...). We've had 2 product owners since the OG product owner made that decision, so it could just be the product owner who made the decision thought they'd be long gone by the time it became an issue.
You're making assumptions about people you've never met, you don't know me and you don't know what motivates me.
You aren't as good at "reading between the lines" as you think you are.
---
From your profile: My main programming language is Perl
Oh, it all makes sense, you're hurt that I called Perl 5 old! That's funny. I've never written production Perl, I am not making a judgement on the language.
> Because I guarantee that whatever language and toolset you are using now, you'll need to be able to switch at some point in your career.
Yeah, but the motivation to learn Perl 5 as your next language is about as wise as learning COBOL as your next language.
That's probably why parent is finding it hard to get his developers to work on it - lots of effort for negative gain[1]. Anyone wanting to learn Perl 5 in 2023, for no additional money, is probably legitimately crazy.
I don't understand why you don't see the problem that parent has - no one wants to learn Perl 5 because it is a dead-end, and takes up energy that would otherwise be spent moving your career forward.
[1] The opportunity cost is immense - the time used to learn Perl 5 enough to maintain the legacy code is time that could have been used to learn a current language that results in a payoff.
And that is the problem.
I don't know how bad that code is - a lot of Perl code from that period is not good - but learning enough Perl to have a shot at it literally should take a competent developer a few minutes if you had someone explain it to you.
You might find the language weird. $ means "the". @ means "these". % indicates you're building a lookup. Which you then access with braces. So %foo is a lookup. And $foo{$bar} should be read "the foo of the bar...".
Early Perl 5 means it probably doesn't use references or objects. You do use regular expressions. While regular expressions are built into Perl in a way that makes them easy to use, Perl-like regular expressions are in pretty much every language. So the effort you need to use them is directly portable to Python, JavaScript, Java, etc, etc, etc.
Fluency takes a lot longer. But getting to the point of "I can puzzle my way through a language I don't know well" should be doable very quickly. And it is a skill that every developer should build. Because I guarantee that whatever language and toolset you are using now, you'll need to be able to switch at some point in your career. And practicing in advance will help you. Plus being the person who can puzzle out old ganky code in another language lets you be a hero in fun ways!