MUMPS is everywhere and nobody knows it

Ask ten engineers what MUMPS is and nine will guess a disease. The tenth might mumble something about “an old language.” Both answers undersell what’s actually going on, because if you’ve been to a hospital in the last decade, MUMPS almost certainly touched your medical record.

I can say this with some confidence because I wrote MUMPS professionally for years. My job was building systems that talked to state DMVs, pulling motor vehicle records, driver histories, title and registration data. Every state has its own quirks, formats, and decades of baggage. MUMPS sat behind a lot of it, and plenty of the integration layers on our side were MUMPS too. I’ve debugged more ^DMV globals at 2am than I care to admit.

What it is

MUMPS stands for Massachusetts General Hospital Utility Multi-Programming System. It was built in 1966 at Mass General to run clinical data on a PDP-7. The modern name is just M, but everyone still calls it MUMPS.

Here’s the part people miss: M is not just a language. It’s a language and a database, fused together. You don’t import a driver, open a connection, serialize a struct, and hope your ORM generates decent SQL. You write to a variable. If the variable name starts with ^, it’s persistent. That’s it. That’s the database.

SET ^Patient("12345","name")="James"
SET ^Patient("12345","dob")="1987-03-14"

Those values survive restarts. They’re indexed. They’re transactional. They live in a sparse, hierarchical, multi-dimensional tree called a global. No schema migration. No ORM. No round trip.

Why it refuses to die

People assume MUMPS is legacy in the pejorative sense, crusty code nobody touches. The reality:

• Epic, the largest electronic health record vendor on earth, is built on MUMPS (via InterSystems IRIS/Caché). If you’ve been treated at a major US hospital, your chart was read and written in M.
• VistA, the VA’s EHR, which was considered one of the best EHRs ever built for decades, is M.
• Ameritrade, Bank of England, European Space Agency, various credit card processors. M has been quietly eating latency-sensitive, transactionally dense workloads for sixty years. The reason it sticks around is not inertia. The design is good for a specific shape of problem: deeply nested, sparse, hierarchical data where you need read-your-writes consistency and microsecond-level access. Try modeling a patient chart in Postgres, then try it as a global. One is painful. The other is four lines.

The syntax is insane (in a useful way)

Commands can be abbreviated to a single letter. A fully valid M program:

F I=1:1:10 S ^X(I)=I*I W !,^X(I)

That’s a loop from 1 to 10, squaring each number, writing it to the database, and printing it. Nine tokens. No imports. No boilerplate. No connection pool.

This was designed when memory cost more than a house, so terseness was survival. Now it looks like line noise. But the brevity isn’t the interesting part. The interesting part is that the persistence layer is a first-class citizen of the language itself. Modern languages bolt databases on with libraries. M treats the database like you treat a hashmap.

What modern stacks could learn

We spend enormous engineering cycles papering over the impedance mismatch between application memory and storage. Caches, ORMs, migrations, connection poolers, read replicas. All of it exists because your program’s data structures and your database’s are different universes that have to be reconciled.

MUMPS’ bet was: what if they were the same universe? You get:

1. Zero serialization overhead. The language knows the storage format.
2. Sparse trees for free. A global with ^X(1,"a",99) and ^X(500000,"z",1) costs only what those two paths cost. No allocated rows, no schema.
3. Transactions at the language level (TSTART / TCOMMIT).
4. Decades of tuning on specific access patterns: per-key latency in M systems regularly beats Redis on certain workloads because there is no network, no protocol, no client library. It’s not perfect. Type safety is a joke, tooling is stuck in the 90s, and finding engineers who’ll touch it is its own operational risk. But the underlying model, a language whose primitives are your persistent data, is arguably more coherent than what the modern stack has converged on.

MUMPS is the best argument I know that “old” and “obsolete” aren’t synonyms. A language from 1966 still runs a meaningful fraction of the healthcare and financial systems you depend on, because it solved a problem the industry gave up on and routed around with complexity.