I've just been asked to "upgrade" a Perl project, last updated in 2012, to PHP 8

I'm not a #Perl expert

Or a #PHP expert

Current mood:

@cypnk That's a weird description of the task to rewrite a whole software in a different language.

Well, you can probably actually upgrade the app to latest Perl 5.42. #Perl has very strong longterm stability and the app might just run fine. Then you can do small incremental improvements from there.

Maybe better have a modern Perl app than no functional app at all?

@dboehmer That's the common sense approach

I would suggest that they keep the project as Perl, but they're very strongly motivated to switch languages. I still think it's inappropriate to make a huge change like this since there are just too many edge cases

I think my week is going to be full writing a whole new thing in PHP instead of trying to convert this

@cypnk @dboehmer
Using the old system as de facto requirements is the sane pivot, if it's small enough (which it sounds like, from very little hints). Finding all the hidden features may be easy or hard.

[Otherwise, strangler fig pattern as s/o else mentioned, retrofitting layers of tests, reverse engineering would be the path, but that's not one person week.]

@BRicker @dboehmer It's luckily not a large enterprise application or anything like that. Just an evolved "Small Series of Shell Scripts" (but in Perl) that are now doing much more over decades and integrated into their workflow

That's still a huge number of things they're doing, but small sections at a time can be removed without taking everything down

This will definitely be a slow slog

@cypnk
Best wishes for you.

If you wind up needing Perl5 deciphering clues, and don't have budget for senior advice by the hour (OTOH ping me if you do), you can ask under hashtag here, Perl FB groups (one is polite), @Boston_PM mailing list.

@cypnk does it have tests? *duck*

@castaway "Tests" ahahahahaahahahaaaaaa *cough* *inhale*

aaaaahahahahaha

@cypnk thought that might be the case somehow ..
@castaway @cypnk
Our usual advice for legacy support, whether updating or porting, is to complete (start and complete) the test suite FIRST.

@cypnk My condolences.

Strangler Fig is your friend here. Build a new one and slowly have it replace the old one, as a proxy. There's no direct conversion path that's feasible.

@cypnk
is there actual Perl too?
or is it PHP being called Perl because it looks similar (which was intentional by PHP originators) ?

(PHP 8 and 2012 is a mismatch; from 2012's PHP5 to modern PHP8 will be painful. Even a single big-version PHP conversion hurts some, but +3? Ouch.)

@BRicker To be fair, I think the last time the "folks in charge" actually worked with computers was when Lotus 123 was king of the office

There is to be no more Perl, which is a shame because most of their processing was so well done at the time (original dev retired in 2018)

@cypnk *sigh* so familiar.
We have several consultancies that could update and support legacy Perl5 applications. (I'm mostly retired but help one of them from time to time.)
But if they have decided to reimplement in PHP8, wow. (I gather it's less of a security disaster than 4,5 were. Stlil quite popular at low end, and as underlying platform but.)

If they have any budget for expert reverse engineering of the legacy Perl, ask. But usually there's no budget ...