Pick your poison. Either you evolve your language to keep people interested and old code becomes stale and eventually stops working, or you don't and you lose your community and interest in the language, like Perl.

We run twenty year old Perl scripts on new hosts at work all the time, with little to no change required in them. We have lots of microservices written in Perl over the last decade or more, and those generally have very little to no problem being ported to new systems as well. The problem now? Finding people that know Perl or want a job writing it.

It doesn’t have to be that way. 10 years since Go 1 and almost all Go programs written then will run correctly, unchanged, against Go 1.19. It takes a lot of effort but the effort pays off big time. Any programming language that wants to survive the test of time should push hard on maintaining compatibility imo.

I think people lost interest in Perl because Python was just a better language for a lot of people’s use cases (and arguably a lot less mysterious). And the focus on Perl 6 (now Raku) arguably distracted a lot of people from Perl 5 and then took too long to mature. (At least that’s how it looked from my outside perspective.)

I wasn't very clear, but I view this specifically as something interpreted languages have to deal with far more than compiled languages. Compiled languages have a slightly different set of trade offs that make this less of a problem (less, but not nonexistent).

> Python was just a better language for a lot of people’s use cases

I won't argue that about the short term, but long-term? Long-term the difference in policy in how it deals with changes ends up at exactly the problem we're discussing. The fact that (IMO) pyenv and virtualenv are needed to manage python deployments in any sane way is evidence of this.

Long-term a lot of projects that ended up using Python would likely have been better served by Perl because of the expected target and lifecycle of the programs in question. There are a lot of aspects of languages which aren't necessarily the thing people were thinking of at the time that they do think of now, because of very negative examples. Examples such as package distribution, which Javascript has had numerous problems with in the past with NPM, and Python occasionally still struggled with (I'm looking at you, pip, and your CLI search interface brokenness).

These days new languages take package management and deprecation policies and cycles and how to deal with long-term stability extremely carefully, because of the examples of Perl and Python and Javascript, etc. At least the ones that plan to have any real adoption do. Rust is a somewhat recent example of that. Look at all the effort they put into making sure they got those aspects as correct as they could and communicated them well to users. I don't think Rust would have nearly as many people using it or interested in it if they didn't give those the importance they did (I imagine C# and Java are similar, but I follow news about them somewhat less).

An exception is C++, which HN loves to hate, but has managed to remain mostly backwards-compatible while evolving into a modern language and maintaining a large community.

Same with Java on all points, including the hate.

> Finding people that know Perl or want a job writing it.

Indeed. Although writing Perl is not so bad, reading not so much.

It's not that I think reading it is necessarily bad, but Perl does shift the onus of writing from making it correct to making it legivlem later. It's easy to write correct perl code, there's often many ways to do it because the language tries to do what you want for you. That unfortunately makes it harder to read, as when not in the exact same frame of mind, those shortcuts the language does for you are harder to intuit later.

I think the total amount of effort required to write good legible code is about on par with it's contemporary languages if you take the time to write it well, but it's hard to resist being able to write it quickly and be done because it's easy to ignore the problem of tomorrow you're creating by being so quick and productive today.

Are you being serious? Have you tried to get a "modern JS app" or Python web app running (safely, w/o massive security vulnerabilities) that is even a few years old?

All code rots, and it rots quickly. Its the a reality of modern software.

I am able to build, run, and use oneko-1.1 from 1995, unmodified on a MacBook M1 Max. It's been almost 30 years, but that cat is still cute when it chases the mouse cursor!

This may be a bit of an extreme example, but generally the unix-y APIs have been relatively stable over the decades, including X11 as we see.

    % ls -l
    total 176
    -rw-r--r--  1 foo  staff    547 Sep  9  1995 Imakefile
    -rw-r--r--  1 foo  staff  15666 Sep  9  1995 Makefile
    -rw-r--r--  1 foo  staff   7545 Sep  9  1995 README
    ...
    -rw-r--r--  1 foo  staff  33472 Sep  9  1995 oneko.c
    ...
    % xmkmf
    mv -f Makefile Makefile.bak
    imake -DUseInstalled -I/opt/homebrew/Cellar/imake/1.0.8_5/lib/X11/config
    % touch DarwinMachineDefines; make CFLAGS="-I/usr/X11R6/include -I/usr/X11R6/lib --include=stdlib.h --include=string.h --include=unistd.h"
    cc -I/usr/X11R6/include -I/usr/X11R6/lib --include=stdlib.h --include=string.h --include=unistd.h   -c -o oneko.o oneko.c
    ...
    % DISPLAY=:0 ./oneko

If you want to try for yourself, you need XQuartz (to have X11 in the first place), and imake from e.g. homebrew, because it's apparently not part of the XQuartz distribution. Don't forget to start XQuartz. That's all.

That's kind of the beauty of C... But this trivial example doesn't equate to most of the production code that humanity relies on now.

Yes, agreed, this is nothing more than a cute toy, and not anywhere close to a full-blown productivity application. But it does show some fundamental API (and language) stability, and especially with X11 in the mix I really had anticipated more problems.

It's not even a particularly cherry-picked example. One day a few years ago, I suddenly remembered that cat, and went out to see if I can still find it. I tried to build it more just for kicks and remember being surprised when it not only "just built", but even "just ran", on my Mac, for which it wasn't even for.

Yeah, something bigger will most likely push back more, especially as soon as more dependencies than just the C library itself and X11 come into play. Though overall my track record in building ancient C stuff with an acceptable amount of changes is pretty good!

It's the unfortunate reality of software, but it's not an immutable law.

The Microsoft example is important. I've never been a fan, but I stand in grudging respect for what they've accomplished with their products as far as backwards compatibility goes, which has significant and enduring value.

Emulators are another example of how software can be long-lived with the right attention.

Personally, I think we have operating environment conceptions all wrong. We continually pay for or fête new versions and thus incentivize change for change's sake. We might do better to respect or even pay for continuing compatibility.

> The Microsoft example is important. I've never been a fan, but I stand in grudging respect for what they've accomplished with their products as far as backwards compatibility goes,

I was a PM for Visual Basic back in the day. A huge amount of work was done within dev and Office to work around problems with Adobe, Borland, etc. so that compat wasn't broken. It was frustrating and heartening.

It is incredibly sad that many/most games that were released for Mac or Linux more than about 4 years ago will run better in an emulated windows environment on those platforms than they will natively (if they run at all).

I think Windows' focus on backwards compatibility is part of what made it the default gaming platform on personal computers. Macs will never be a serious platform for gaming, even if they begin offering more performance, as long as they keep their obsession with wiping the slate clean and throwing developers off every 5-10 years or so. (I mean... 680x0, PowerPC, Mac OS X, x86, 64-bit-only, Apple Silicon, just how many breaking transitions do they have to go through?)

Nobody's trying to argue that python and javascript aren't terrible, just that there are other languages and APIs that are standardized and maintained by people who prioritize reliability over following dumb trends that bloggers come up with.

C is a great example of this. Even if the ABI changes, in the worst case scenario a well-written C program only needs to be recompiled.

This is only true for languages that are not taking a long-term vision into account.

Run some 8 year old Clojure Github project, should be fine.

Try a Common 20 year old Common Lisp project, you shouldn't have an issue.

LISPs all seem tremendously resilient.

I wonder what intrinsic quality makes a language long lived, rather than blame communities and whatnot.

Another stalwart is Pure Data, the DSP language I am very fond of. It's based on atomic principles. Indeed the primitive processing elements are called Atoms, being irreducible ops like multiply, add, sin and cos. There really isn't much that can change. For C as for LISP, especially Scheme, it's hard to break them down any further, yet they are high enough level to be useful for programming. There's some sweet-spot to be found.

Ha, I just wanted to bring up Pure Data as example. It takes backwards compatibility very seriously. Patches written 20 years ago should run just fine on any recent Pd version. In fact, Miller Puckette strives for at least 50 years of support. Pd just had its 25th anniversary, so there are at least 25 more years to go :-)

Run a forty-year-old FORTRAN program on your mainfram... oh, you already are?

This isn’t entirely true about Clojure, because there are things that have broken as new Java versions have come out (especially with modules and exports etc). Obviously you can still run Java 8 if you want though.

This can happen, but it's not very common in my experience. E.g., I tried an early version of Clojure (1.0, I think) on Java 13 and it ran just fine, although I didn't seriously test it

Sure, I wouldn't expect clojure.core to break ever. Maybe we'll get some future version based on Project Loom and that'll require some thought.

But I've had to work out weird command line incantations for various libraries that touch crypto or JavaFX namespaces. And things like Quil are still in a weird state on modern JVMs.

I would love some concrete data on this! Has anyone done any studies?

I just found some of my C and C++ code from around 2001. I just needed to add one missing prototype I'd let be implicit in my sloppiness, and it all built and ran just fine.

Just runs a lot faster. :-)

I'm currently bulding a SPA to replace a 25 year old X Window app. That app still builds on modern Linux systems despite being unmaintained during that time. Seeing that old CVS repo brought back some memories. The customer wants to modernize.

By comparison, the SPA is a nightmare of tooling and dependencies that will be unsupportable in a few years without constant maintenance and updating.

Python I can understand because of the 2 to 3 transition.

But JavaScript that worked in 1995 still works today. All of it.

Presumably that's not true for any code that uses modern keywords such as class or super or await as variable names.

It is, actually. Well, "class" and "super" were never legal even before they became keywords, because the language was designed to evolve and those were obvious things which might be useful later. But "await" still works as a variable name outside of an async function, even today, precisely so that old code still works as it used to. There are some contortions in the specification (and implementations) required to make this work, but it does work. (I am one of the current editors of the JS specification.)

Huh! Fair enough.

I can't recall as I don't do Javascript development regularly, but doesn't that require `"use strict"`?

Modern JS apps I encounter are packaged up with npm and I rarely have trouble running them.

Python, I agree, is a challenge. I don't use it. I used to; I concluded it was too much hassle most of the time to maintain my Python working against other people's Python. Coupled with the lack of static type checking, I pulled it off my quick-grab list years ago (though with the growth of mypy, pip, and conda I may revisit it some day if I get bored with my current tools).

Go code is pretty stable. Java seems downright calcified. And, of course, the whole C library space may as well be igneous stone. You can get FFTW version 3, for example, built from the relatively recent date of last year, but FFTW has a version 2 stable release dating back to 1999.

JS apps nowadays have so many layers that often something breaks over time or if you run it with the wrong version of node.

Frontend post react is an absolute nightmare: My experience with a fleet of semi abandoned next.js static websites is pretty terrible: just in months something stops working in my pipeline on vercel and I need to spend time to debug it. Running things locally is even worse, I just change the code, push and hope for the best.

Python is a downright nightmare: between 2vs3 and pip, egg, venv, I usually just salvage the code I need and try to make it work or convert it to something saner (eg. I did that with an opencv algorithm I found - I just transposed it to rust + the same opencv api calls). My favourite story happened literally 2 days ago. I was trying to install a dependency (keras_ocr) and I kept failing on some dependency; I tried installing that dependency manually and it worked but no success on installing keras_ocr. Eventually I updated pip and it started working.

I had huge problems running old Go software, I think I succeeded once after a lot of pain and gave up the other times.

I had fairly good results with ancient C, C++, Java and Haskell. Probably because they started before we had cool and glamorous developers on twitter selling you a course and not maintaining his 200 leftpad libraries.

I'm curious to see where Rust will sit in a few years.

Hey jokethrowaway. I'd love to get more color on your experience upgrading your Next.js sites: feel free to email [email protected].

- On local: `npm i && next dev` is guaranteed to be stable.

- On remote: your pipeline is guaranteed to be stable.

If you have an example where this is not the case, please let me know.

I could've been more clear in my original post. I'm not just thinking about "getting an app running": ruby, rbenv, and bundler has had that solved for many years, and npm, nvm (or whatever and js is stable there as well.

If you take any app built three years ago, you are going to have critical security vulns in libraries you depend on. With java think of the log4j fiasco. With Ruby there are nokogiri or rails things. With javascript there are probably at least a handful of downstream packages that have pretty big security issues. Now you have to update dependencies, and then the real fun begins.

If it a walled-off intranet app on a VPN, or a small CLI app, sure, maybe you can ignore that issue. But if its a public web or mobile app that is gonna see real use, you are going to have to head down the security audit + package update rabbit-hole.

For what I do in my day-to-day, security vulnerabilities are reported by `npm` automatically when updating packages and there are several pieces of nice tooling around identifying the versions that exhibit the vulnerability and getting around them.

I think the `npm` community is going in the right direction and learning from mistakes of the past on this topic.

I mean, bundler goes back a pretty far distance into the history of rails at this point and has been the defacto mechanism of dependency control for ruby for most of its history by now, so barring old gems being yanked you should be able to run any rails app with a lockfile if you also find the right ruby version.

Js (or specifically npm) and python were far slower to adopt this convention, to the point that I think it's fair to say that neither have fully adopted it yet.

Js at least has made almost no backwards incompatible syntax or core lib changes though, which is a point in its favor. Ruby 2 and python 3 were major breaking changes.

For JavaScript, I generally assume backwards-incompatible changes are a non-starter because of its embedding into the browser as its killer app. At this point, we really don't know what websites will break if backwards-incompatible JS changes are made.

Ironically, this has made JS a very stable language (though APIs do occasionally drop out or change drastically for security reasons).

I have a VERY old rails project that I started back in 2005 when Rails was like version 0.8 (when migrations were just a series of .sql files you ran in order). I continued working on it for a few years and by the time I stopped, I had upgraded it rails 2.1.

I recently wanted to play around with it again, and I was able to get the entire thing running in Kubernetes. You can find docker images for Ruby 1.8.7 still, and the Rails 2.1 gems still installed fine. It might not be up to date security wise, but it runs!