[ajsnigrutin]

Yeah, it's stable.

I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.

[hnlmorg]

In a previous company, I had to support TypeScript code that wouldn't even survive 12 months without something breaking upstream. Granted there were a lot of other things that company did wrong...a hell of a lot! But it's insane how little importance people seem to place on code longevity these days.

[bloopernova]

Too many people in leadership value features over fixing tech debt.

[hnlmorg]

I’m not on about fixing tech debt. That’s a completely different problem to picking boring technologies that don’t need constant ongoing maintenance just to keep running.

Tech debt is going to happen regardless of the technologies you pick. But some technologies require more effort to keep up-to-date than others.

I’d also argue that keeping technologies up-to-date isn’t “tech debt”. It’s operational overhead. Tech dept is something else entirely.

[jimbob45]

In my experience, tech debt often requires too great an investment to fix so the team just ends up bikeshedding to show progress but without real benefits.

Look at C. Each revision has added a bunch of minor fixes but has never addressed the core issues of the language that realistically require a rewrite (function pointer syntax, undefined behavior, null safety).

And there’s the fact that features bring in money and tech debt simply doesn’t. It’s still a business at the end of the day.

[j33zusjuice]

Omfg, if that’s not the truest statement I’ve read on here… this has been a major issue at the last several places I’ve worked.

[downsplat]

Right. I started a perl codebase in 1999, which has slowly evolved and is still one of my main projects to this day. The language has slowly improved, there are decent libraries for everything you might want to do, and I've basically never had to rework or throw away my code because of incompatible changes in the language.

For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.

[bloopernova]

Parallel is written in Perl, it's still going strong after a couple of decades.

[szundi]

This is an insightful comment about maintenance.

[officialchicken]

I agree - because it hints to new development too.

To say "This isn't going to work in 7 years", and be taken seriously would be a welcome reversion to current practices against good engineering.

[helf]

And you can tell based off all the other comments on here that you and I are in the minority on liking that it's stable. Even with all its faults.

I, too, have 20 year old perl scripts that still run fine.

I randomly have to bang my head on my desk over bs with python and php incompatibilities between versions.

Pets perl

[hpcjoe]

I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.

My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.

Perl just works.

[nocman]

No, you are not alone.

Over 25 years of Perl experience. Still writing new stuff daily, both for work and personal use.

[liveoneggs]

Are you kidding? Python code bases break week-to-week because pip is full of unversioned transitive dependencies, broken distro nonsense, and who knows what else.

Major version changes are easy and rare.