Hacker News Reader

Comment by ilcavero | Hacker News Reader

obligatory reference: https://thedailywtf.com/articles/a_case_of_the_mumps

Well, try to run C++, C# or Java on a PDP-7 or PDP-9.

In 1976, the year of the first standard, massive hospitals with thousands of patients run on MUMPS, on PDP machines with 8K to 24K of core memory and many concurrent users.

I don't think anyone is really blaming MUMPS for the limitations it had to work with 1970s tech. The story was more about how terrible it is to work with in the 2000s and the surprising fact that it's still in use today in certain niches.

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.

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

> 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.

This article is terrible and I hate that people always bring it up whenever MUMPS is mentioned here.

MUMPS is easy to read, understand and maintain when written well.

These examples (and the Wikipedia ones) are from code written when hospitals needed to run their whole EMR with extreme storage constraints, so more terse code was necessary to fit more on the disk. Of course they aren’t readable by modern standards.

The problem with MUMPS (and RPG) is that there's so much legacy code written in the old style that you have to learn to read and write it anyway.

Dude, chill.

That article is humor, not an essay on the merits of MUMPS.

It was entertaining to read for me back in the day, especially as my first programming job was on a COBOL system from the 80s. That in the mid 2000s.

Reply on news.ycombinator.com