Hacker News new | past | comments | ask | show | jobs | submit login

Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn't turn that feature on.

The rule has generally been that you can take a 20 year old Perl script and it will still just run. This has its own complications though, as it makes it harder to advance the language, and then people feel it's being left behind (the Perl 6 stuff came after that feeling developed).

It's a longstanding problem in language design and communities, stability vs advancement.




Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.


Lots of CPAN stuff is just plain Perl code, so the, "it just works" keeps working, too. It's to the point where a lot of "competing" Perl modules that try to solve the same problem have similar/same API's (but under the hood, rely on different things) - sometimes that is to solve the, "Well, the more popular choice went off and did something interesting in $VERSION+1, but we like the old way"

Also, if you desperately need an older version, you can usually install that older version rather than the newest.

Anyways, there's things you can do. I still work on code I started in my dorm room (in the 90's). Cranky CPAN modules aren't too big of a problem.


The old versions of modules are available, if you don't happen to have the exact same code present.

Core modules are all I would worry about, but I'm pretty sure those are held to the same standard as far as backwards compatibility.

One or two modules might have been ejected from core or moved into core, but those should be easily found on CPAN as well.

In the end, getting something working from scratch on a newer Perl that has a lot of CPAN dependencies (as opposed to just updating Perl) might be a little annoying in that you have to track down all the module versions, but it's far from impossible, or even all that hard.

For example, the CGI module[1], which was a core module but historically seen as fairly bad (at least as of now, and at least in some of its uses, it supported a wide set of use cases), it was removed from core and housed on CPAN. If you follow the link provided and check the past versions (dropdown as part of the module path and name), you'll see there are many versions shown, possibly every public version, and going back to 1998 for CPAN, and 1995 for 1995 for the BackPAN. Each of those is visible as an item with it's documentation at the time and the module available to download and use. You can also access the CPAN testing matrix[2], and if you dig around you can actually find the results for some tests back in 1999.[3]

If I was responsible for getting some old Perl app to run on a more modern system, I would by much more worried about the OS changing in a complex way than I would about getting the Perl code to run again as expected. Which is to say, I wouldn't be worried much at all.

1: https://metacpan.org/release/CGI

2: http://matrix.cpantesters.org/?dist=CGI+4.44

3: http://matrix.cpantesters.org/?dist=CGI%202.55


SaaS modules too, a lot of services have their API modules and examples provided in various languages. Perl is often not one of them. In some cases where it is, it's out of date or plain old broken. As an example (which is understandable, no hard feelings) I had to edit the SendGrid modules to fix a bug when I tried, and there were issues on GitHub that have been ignored since before it became officially unsupported in 2016.

I usually use Python these days when dealing with SaaS apps since the ecosystem is much better, and I want to learn it anyway.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: