I did most of Advent of Code last year code golfing in MUMPS (running on Caché), with the additional challenge on up to and including day 7 doing without literals - that's to say no numbers and no strings. It was good fun - https://github.com/dominique-m-aoc/aoc-2025/blob/main/day03p... for day three part 1 for example. Or day 7 part 2 where the alphanumeric chars spell a story with only two nonsense words, with almost all the chars being on their own: https://github.com/dominique-m-aoc/aoc-2025/blob/main/day07p... It is a neat language but even more so a neat overall system and bag of concepts that I feel annoyed we haven't seen more of...
That's cool; amazing you indeed coded in MUMPS and not in ObjectScript ;-) Caché is (was) a great technology; ironically they tried to look like a relational database in the nineties, and then eventually came the NoSql boom. How did you get to MUMPS?
First job out of university and stuck around with it for the next dozen years, probably longer than sensible... in the context of maintaining a bag of software that got put together in the mid-80s, a substantial module of which continued to enjoy some moderate success to this day.
Also, the marketing term was post-relational if I recall correctly, the funny thing about that being that it was really pre-relational at first. Also, I forgot, it was IRIS this AOC stuff runs on - the $ZV actually needs that "R" in IRIS so it knows what label to jump to... and what file mode to use... it's wonderfully cursed ;P
One thing I miss about Caché/Ensemble/IRIS is the three different paradigms for manipulating the same bits of data - the whole object layer, SQL (with pre-compiled embedded SQL an option), and the raw global access.
For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.
I’ve been working on a project to celebrate the anniversary of MUMPS and its first standard.
For those unfamiliar, MUMPS is an imperative language famously born at Massachusetts General Hospital in 1966. Its defining characteristic is that the language and the database are deeply integrated, acting as an early NoSQL database decades before the term existed.
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.
I did most of Advent of Code last year code golfing in MUMPS (running on Caché), with the additional challenge on up to and including day 7 doing without literals - that's to say no numbers and no strings. It was good fun - https://github.com/dominique-m-aoc/aoc-2025/blob/main/day03p... for day three part 1 for example. Or day 7 part 2 where the alphanumeric chars spell a story with only two nonsense words, with almost all the chars being on their own: https://github.com/dominique-m-aoc/aoc-2025/blob/main/day07p... It is a neat language but even more so a neat overall system and bag of concepts that I feel annoyed we haven't seen more of...
That's cool; amazing you indeed coded in MUMPS and not in ObjectScript ;-) Caché is (was) a great technology; ironically they tried to look like a relational database in the nineties, and then eventually came the NoSql boom. How did you get to MUMPS?
First job out of university and stuck around with it for the next dozen years, probably longer than sensible... in the context of maintaining a bag of software that got put together in the mid-80s, a substantial module of which continued to enjoy some moderate success to this day.
Also, the marketing term was post-relational if I recall correctly, the funny thing about that being that it was really pre-relational at first. Also, I forgot, it was IRIS this AOC stuff runs on - the $ZV actually needs that "R" in IRIS so it knows what label to jump to... and what file mode to use... it's wonderfully cursed ;P
That said, it doesn't hold a candle compared to this: https://stackoverflow.com/questions/4151554/need-mumps-sampl... which is just about the best obscured (or byte-saving rather) MUMPS snippet in existence.
One thing I miss about Caché/Ensemble/IRIS is the three different paradigms for manipulating the same bits of data - the whole object layer, SQL (with pre-compiled embedded SQL an option), and the raw global access.
Built-in hierarchical DB? Neat!
DB access using same syntax as local variables? Neat!
Datetime epoch in 1841? Ok, sure.
Stringly typed with literally no other types? Uh…
Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night
It had some neat ideas, some alright ideas that were reasonable in the context it was created for, and some absolute nightmare fuel.
Already discussed here: https://news.ycombinator.com/item?id=48707444
I don’t think that’s the same discussion.
For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.
I’ve been working on a project to celebrate the anniversary of MUMPS and its first standard.
For those unfamiliar, MUMPS is an imperative language famously born at Massachusetts General Hospital in 1966. Its defining characteristic is that the language and the database are deeply integrated, acting as an early NoSQL database decades before the term existed.
See here for more information about the project: https://github.com/rochus-keller/mumps/
There are pre-compiled versions of my MUMPS 76 interpreter in case you want to play with it.
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.