[Jach]

Not to mention working programmers are expected to keep up with changes to C++, Python, Java, JavaScript (and its frameworks), Go2.0, etc., many of which constitute "new language" levels of different, not to mention actual language changes like JS -> TypeScript, or Java -> Kotlin, or ObjC -> Swift, and even occasionally mobile lang -> C++ (maybe just a shared core). There's plenty of evidence that it's not that bad. And meanwhile, Common Lisp hasn't changed, code from the 90s works unmodified, the only things to keep up with really are which libraries and implementation-specific features are new/interesting/in fashion (same as any language ecosystem).

[pjmlp]

It is quite different, as those are incremental changes, and most of them can be ignored until there is a requirement to use a library or SDK that makes more recent features a requirement.

Any corporate developer knows the pain of actually being allowed to upgrade toolchains, traditionally lagging behind several years behind lang v-latest.

[cess11]

I much prefer upgraded libraries and tooling over sticking to deprecated stuff.

Handling upgrades is like doing the dishes, it has to be done, there's no use complaining about it.

[pjmlp]

Someone has to put the money on the table for those upgrades.

This is the great thing about consulting instead of product development, developers are made constantly aware of their hourly rates.

No budget for spending time on upgrades, no upgrades.

[cess11]

Don't work for people that disallow upgrades and maintenance. Don't make deals with people who don't understand that software is finished when it's dismantled and the code deleted.

[pjmlp]

Easier said than done, I have seen a lot since 1980's.

[cess11]

Do what you have to survive, then bail when you can.