Item — HN Reader

My project and the referenced primer are about the 1976 standard.

But many MUMPS based systems are still in operation and maintenance today; and not many significant systems in IT reach a 50 year lifetime.

A modern JavaScript, PHP or Python system (languages with similar limitations for large-scale software engineering as MUMPS) written five years ago hardly works today because dependencies significantly changed or are no longer available. In 50 years (or even in 10) it will be astronomically expensive to keep a current Node.js system alive. But you still can run an unmodified 1985 MUMPS system on a current InterSystems IRIS server.

The main problem with critical MUMPS systems today is less technical, but mostly staff shortage. The same applies to COBOL, or Ada, or even Java.

> A modern JavaScript, PHP or Python system written five years ago hardly works today because dependencies significantly changed

thats why the best practices are version locking and containers. your dependencies cant change from under you when its pinned to a specific hash. the only way it can break is if npm or pypi shuts down and nobody including you has an archive which is extremely unlikely.

and you can run a oci image in 50 years unmodified unless linux stops development decides to break userspace and theres no working translation layer for the next system. even if it becomes obsolete the spec is still there and someone will build a "docker on future runtime X" if they need it.

What about running that same codebase on open source versions of mumps such as GT.M or Yottadb?