The core idea-a language with a built-in persistent key-value store-is actually pretty cool.
The classic implementation is filled with horrible warts, although arguably many of them were helpful in squeezing a production multiuser system into the tiny resource constraints of the original 1960s implementation platform (18-bit PDP-7, same machine as Unix was birthed on, although Unix soon moved to the 16-bit PDP-11, which was in practice more spacious)
Modern implementations make many of those warts optional, although they still support them for backward compatibility
The biggest problem with the language in practice is that many major code bases (e.g. VistA) are still predominantly written in the legacy extremely terse coding style rather than a more modern readable style. I do wonder why there isn’t more effort put into migrating to a more modern style, especially since with the kinds of tools we have nowadays that migration could be (at least partially) automated.
The VA still requires "routines" to be < 20000 characters. So programming with single letter commands will always be ingrained in M code. Besides its a lot less typing :)
The biggest problem I have with the ecosystem is the $P (PIECE) command (splits ^-delimited strings) bled into the GUI codebase so everywhere the devs wrote code like if Piece(3)=1 making it impossible to reason about.
> FoxPro(dBase family) was a much better take on the idea
xBase is arguably a very different idea - it is based on flat-file/key-indexed databases, akin to VSAM on IBM mainframes, but wrapped in a 4GL. The experience of xBase is very similar to many mainframe 4GLs, what made it distinctive was providing that experience on low-end platforms (it started out on 8-bit CP/M systems, but it was on 16-bit DOS that it really took off)
By contrast, MUMPS has multidimensional associative arrays as a basic data type, and the difference between temporary (in-memory) and persistent (on-disk) arrays is simply whether the variable name is prefixed by a caret. Perl’s tied arrays are close, but tied arrays are a rather peripheral feature of Perl (many Perl code bases never use them), but a central feature of MUMPS
Oof. Unrelated to MUMPS, but the worst I've ever run into was a reimplementation of PHP's register_globals 20 years after it'd been patched out as a security nightmare, because the developer enjoyed the convenience.
One fun thing about MUMPS is that if you don't use the newfangled "new" keyword when declaring them, variables iirc are all global to the file. Or record, or whatever not-quite-a-file entity contains source code in MUMPS systems (8 character hard limit on filenames)
And of course some code ends up relying on ambient global state to function properly, so the codebase is strewn with "environment setting" methods that set up the required globals before you call the functions that rely on them.
The other fun one iirc is that calling a function inside the "true" branch of an IF can clobber the global TEST flag and cause the "false" branch to execute as well, since the "else" keyword relies on $TEST to decide what to do. The fix is to end it with a noop "if true" to unclobber $TEST.
The other worst MUMPS code was MUMPS code that used string concatenation to generate more MUMPS code from the worst DSL you've ever seen, MUMPS code that seemed to partially implement a MUMPS interpreter...
I work in MUMPS daily and this is such an odd take to me. It's entirely possible to write very readable and maintainable MUMPS, and I find it fairly pleasant to write. There's lots of poorly written code, sure, but you can write bad software in any language.
I learned MUMPS years ago at UC Davis (Dick Walters, one of the language maintainers, was tenured there) and I found it a really interesting, but deeply weird language. Walters himself was a considerate, patient dude with me, struggling to deal with at the time a truly strange beast.
That's where I heard about it. I was a student from 2000-2009 when Sean Davis was around.
If anyone remembers, CSIF used NIS (not even NIS+) and all password hashes were available to everyone on any cluster machine by running `getent passwd`. John the Ripper found about 90 short/dictionary-based passwords within one minute on a machine of that era.
Part-time MUMPS programmer here for a health system in NYC. I still love writing in it. The rates are way better than other eco-systems (e.g. Python, Java, blah blah) , probably because the eco-system isn't diluted with low-wage workers from India/China. This is because 95%+ of Epic/Ex-Epic employees are American. I would even argue it is the patriotic language of choice due to that reason.
Expected pay of 85-120/hour, which pays way more than my full-time job. It's a fun language to write in, and the adrenaline rush you get when you get a triple index loop working is awesome.
Also random fact - according to Epic HR , the average college GPA of Epic employees was 3.5, which is probably the perfect formula in hiring loyal corporate servants. I always thought it was weird that I had to apply with my transcripts and resume.
> I always thought it was weird that I had to apply with my transcripts and resume.
I similarly thought it weird when Garmin asked me for transcripts when I applied there a few years ago. It had been 15 years since I'd graduated, so I was lucky I still had a couple copies of my official transcripts from back then. After spending the effort to find and scan them in with my 3.8 GPA, didn't even get a phone screen.
I primarily work on clinical data, and from that side, the technology stack—MUMPS included—has its quirks but generally gets the job done. The real dysfunction in U.S. healthcare isn’t the software or the language itself, but the system it’s built to serve. The core issues lie in the incentives around revenue cycle management and the structure of the insurance industry. Blaming MUMPS is like blaming COBOL for bank fees—it’s the system, not just the syntax.
I'm not from US. The dollars were converted from euros. Our Epic/MUMPS installation is 100% tax funded single-payer with no insurance company involvement.
But MUMPS is indeed more a symptom of a rotten industry. E.g. the bidding process that led to this mess was very corrupt, from all sides.
> My city has sunk almost a billion dollars into a dysfunctional Epic pile of MUMPS.
I don’t know if the alternatives - e.g. Oracle Health/Cerner - are really that much better - and if Epic is as bad as you say, I suspect that says more about their corporate culture than choice of programming language
If you don't mind me asking -- how did you find a job like this? I live in NYC, I'm looking for work, I worked briefly at Epic, I don't mind MUMPS, and honestly something involving MUMPS sounds like it's probably more my style than a lot of what else is out there. I don't really know how to look for jobs like this I'm afraid!
That's far too low if those are current USD figures; you're hurting your and others' incomes by working too cheaply in a niché field. I was making $280k TC as a Rubyist at Meta or $10k/week consulting 10 years ago. That's not anywhere near as niché as Erlang/Elixir/Phoenix, OCaml, embedded Haskell, or embedded Rust. Or COBOL. ;o)
It’s purely remote and super chill. Not everyone wants to work on ads/compete with Indians/Chinese. I’d rather make 200k helping clinicians be more efficient using ML than $300k+ optimizing two tower models to increase the CTR on ads.
Went to a smaller company for a short time, than ended up at FAANGs.
Epic had some nice features and it was really cool working directly with nurses and doctors. But it has some churn issues and the software sucks to use, especially with Epic's insistence on "all software built in house". While a good marketing ploy, it results in reinventing crappier wheels.
The description of MUMPS always misses what working with it directly is actually like (at least for me). It feels more like a custom OS than a programming language. Code being stored alongside data so changes apply live in the system, writing schemas and indexes by hand, and the difficulties combining it with other standard programming tools make it a fairly unique experience in 2025.
Way back in the day, while bored at my SaaS MUMPS support job, I wrote a version of the 'artillery' game in MUMPS, complete with graphics and explosions. I still wish I had that code somewhere :)
I just heard about it for the first time today on the Primeagen post where TJ mentioned his first job was at Epic where he used Mumps. I assume that is how this came about timing-wise.
I worked at Epic the EMR company that probably has written more lines of M than any other company. Their EMR suite is the most popular in the US. They have a very high ratio of testers to programmers and I always wondered if this is because their ancient M code base is very brittle.
PSA: POSIX shells (bash etc) do the same thing for && and ||. `true || false && false; echo $?` will be 1, not 0, because it evaluates `true || false -> true; true && false -> false`, not `false && false -> false; true || false -> true`. Don't assume like I once did that they have precedence like they have in C etc :D
This approach is, arguably, more readable because it relies on a simple left-to-right evaluation. Programmers don't have to recall the complex, though often familiar, rules of operator precedence.
RPN is slightly easier to parse and interpret but more difficult for most humans to parse and interpret. This is the middle ground that most everyone can quickly and easily adapt to writing and reading but would still be efficient on most any system.
It’s definitely easier to parse, but you can use shunting yard to do operator precedence parsing using very little extra memory and no recursion. I feel like the language is just poorly designed.
To be charitable to its original designers, information was much less easily accessible in the 1960s than today-although the shunting yard algorithm had been published in the research literature in 1961, practitioners working 5-6 years later may plausibly have been unaware of it-it wasn’t like nowadays where they could easily discover it in Wikipedia or by asking an LLM.
Yeah, that's fair enough. I'm sure a lot of weird / bad language design choices can be chalked up to this (COBOL...). Now that C and Pascal derived languages have been around for a long time, even if you don't know about how parsers work, everyone knows that certain syntax / semantics are at least possible since they're the norm, and I suppose that wasn't the case back then.
I implemented the same in some of my programming languages. If you look into very generic mixfix operators in some languages like Agda, you'll realize that operator precedence is a mess and it feels so much better to get rid of it. Of course, it makes the language unusable as a mainstream language, but it makes so much more logical sense.
The explanation that makes most sense to me is that it's mostly to avoid having to explicitly write out parentheses a lot of the time. Especially for things like polynomials, which are a bunch of multiplied terms added together, eg 3x+2y and not (3*x)+(2*y). And in polynomials you can even drop the explicit multiplication symbol, so it's much neater. And once you've done this for algebra now you have to do it for plain arithmetic as well to make it all match up, and 3*5+2*7 gives the same answer as evaluating the polynomial at 5,7
Not just simplicity-the original implementation was for a very resource-constrained 1960s minicomputer, where a more complex implementation would have slowed the system down even more and left less memory for running the actual business application
The core idea-a language with a built-in persistent key-value store-is actually pretty cool.
The classic implementation is filled with horrible warts, although arguably many of them were helpful in squeezing a production multiuser system into the tiny resource constraints of the original 1960s implementation platform (18-bit PDP-7, same machine as Unix was birthed on, although Unix soon moved to the 16-bit PDP-11, which was in practice more spacious)
Modern implementations make many of those warts optional, although they still support them for backward compatibility
The biggest problem with the language in practice is that many major code bases (e.g. VistA) are still predominantly written in the legacy extremely terse coding style rather than a more modern readable style. I do wonder why there isn’t more effort put into migrating to a more modern style, especially since with the kinds of tools we have nowadays that migration could be (at least partially) automated.
The VA still requires "routines" to be < 20000 characters. So programming with single letter commands will always be ingrained in M code. Besides its a lot less typing :) The biggest problem I have with the ecosystem is the $P (PIECE) command (splits ^-delimited strings) bled into the GUI codebase so everywhere the devs wrote code like if Piece(3)=1 making it impossible to reason about.
FoxPro(dBase family) was a much better take on the idea.
I also dream of something modern like this (https://tablam.org) but is certainly a significant undertaking. Accept partners!
> FoxPro(dBase family) was a much better take on the idea
xBase is arguably a very different idea - it is based on flat-file/key-indexed databases, akin to VSAM on IBM mainframes, but wrapped in a 4GL. The experience of xBase is very similar to many mainframe 4GLs, what made it distinctive was providing that experience on low-end platforms (it started out on 8-bit CP/M systems, but it was on 16-bit DOS that it really took off)
By contrast, MUMPS has multidimensional associative arrays as a basic data type, and the difference between temporary (in-memory) and persistent (on-disk) arrays is simply whether the variable name is prefixed by a caret. Perl’s tied arrays are close, but tied arrays are a rather peripheral feature of Perl (many Perl code bases never use them), but a central feature of MUMPS
You might find some interesting ideas in Lil, which is also a kdb+ descendant: http://beyondloom.com/tools/trylil.html
Worth linking for a hotter take: https://thedailywtf.com/articles/A_Case_of_the_MUMPS
S Y=$C(34),X="W ""S Y=$C(34),X=""_Y X ""F %=1:1:6 W $P(X,Y,%),Y,Y"" W Y,"" X X""" X X
I ran across SHA1 implemented in MUMPS once. And handwritten bitwise operations, since MUMPS doesn't have those as operators.
Oof. Unrelated to MUMPS, but the worst I've ever run into was a reimplementation of PHP's register_globals 20 years after it'd been patched out as a security nightmare, because the developer enjoyed the convenience.
One fun thing about MUMPS is that if you don't use the newfangled "new" keyword when declaring them, variables iirc are all global to the file. Or record, or whatever not-quite-a-file entity contains source code in MUMPS systems (8 character hard limit on filenames)
And of course some code ends up relying on ambient global state to function properly, so the codebase is strewn with "environment setting" methods that set up the required globals before you call the functions that rely on them.
The other fun one iirc is that calling a function inside the "true" branch of an IF can clobber the global TEST flag and cause the "false" branch to execute as well, since the "else" keyword relies on $TEST to decide what to do. The fix is to end it with a noop "if true" to unclobber $TEST.
The other worst MUMPS code was MUMPS code that used string concatenation to generate more MUMPS code from the worst DSL you've ever seen, MUMPS code that seemed to partially implement a MUMPS interpreter...
A statement that writes itself? Neat!
I work in MUMPS daily and this is such an odd take to me. It's entirely possible to write very readable and maintainable MUMPS, and I find it fairly pleasant to write. There's lots of poorly written code, sure, but you can write bad software in any language.
A Case of the MUMPS (2007) - https://news.ycombinator.com/item?id=36268931 - June 2023 (109 comments)
Classic. Probably one of their best articles.
I learned MUMPS years ago at UC Davis (Dick Walters, one of the language maintainers, was tenured there) and I found it a really interesting, but deeply weird language. Walters himself was a considerate, patient dude with me, struggling to deal with at the time a truly strange beast.
That's where I heard about it. I was a student from 2000-2009 when Sean Davis was around.
If anyone remembers, CSIF used NIS (not even NIS+) and all password hashes were available to everyone on any cluster machine by running `getent passwd`. John the Ripper found about 90 short/dictionary-based passwords within one minute on a machine of that era.
Part-time MUMPS programmer here for a health system in NYC. I still love writing in it. The rates are way better than other eco-systems (e.g. Python, Java, blah blah) , probably because the eco-system isn't diluted with low-wage workers from India/China. This is because 95%+ of Epic/Ex-Epic employees are American. I would even argue it is the patriotic language of choice due to that reason.
Expected pay of 85-120/hour, which pays way more than my full-time job. It's a fun language to write in, and the adrenaline rush you get when you get a triple index loop working is awesome.
Also random fact - according to Epic HR , the average college GPA of Epic employees was 3.5, which is probably the perfect formula in hiring loyal corporate servants. I always thought it was weird that I had to apply with my transcripts and resume.
> I always thought it was weird that I had to apply with my transcripts and resume.
I similarly thought it weird when Garmin asked me for transcripts when I applied there a few years ago. It had been 15 years since I'd graduated, so I was lucky I still had a couple copies of my official transcripts from back then. After spending the effort to find and scan them in with my 3.8 GPA, didn't even get a phone screen.
I'm not sure I love paying it with worse health services though. My city has sunk almost a billion dollars into a dysfunctional Epic pile of MUMPS.
But I guess it's nice to see the healthcare software disgrace works well at least for some.
I primarily work on clinical data, and from that side, the technology stack—MUMPS included—has its quirks but generally gets the job done. The real dysfunction in U.S. healthcare isn’t the software or the language itself, but the system it’s built to serve. The core issues lie in the incentives around revenue cycle management and the structure of the insurance industry. Blaming MUMPS is like blaming COBOL for bank fees—it’s the system, not just the syntax.
I'm not from US. The dollars were converted from euros. Our Epic/MUMPS installation is 100% tax funded single-payer with no insurance company involvement.
But MUMPS is indeed more a symptom of a rotten industry. E.g. the bidding process that led to this mess was very corrupt, from all sides.
> My city has sunk almost a billion dollars into a dysfunctional Epic pile of MUMPS.
I don’t know if the alternatives - e.g. Oracle Health/Cerner - are really that much better - and if Epic is as bad as you say, I suspect that says more about their corporate culture than choice of programming language
That was the story why Epic was chosen. It was made to be a dilemma between Epic and Cerner, by design.
In reality it's not a dilemma. In other cities and countries there are EHR systems from other vendors that work less bad and with lower cost.
If you don't mind me asking -- how did you find a job like this? I live in NYC, I'm looking for work, I worked briefly at Epic, I don't mind MUMPS, and honestly something involving MUMPS sounds like it's probably more my style than a lot of what else is out there. I don't really know how to look for jobs like this I'm afraid!
Makes me curious about getting MUMPS to run locally on a Mac. I had great fun with it 15 years ago.
https://hub.docker.com/r/intersystems/iris-community
Should be super easy.
There’s also a native Apple Silicon tarball that I’m not sure is as easy to get your hands on.
https://gitlab.com/Reference-Standard-M/rsm is small, no-frills, really cool. http://yottadb.com if you want one with all the bells and whistles.
The GPA of 3.5 is their minimum for considering a candidate.
Man this is an interesting comment.
>probably because the eco-system isn't diluted with low-wage workers from India/China.
Are there other technologies like MUMPS that have the same characteristics?
Not technology but you need to be a US citizen to get a security clearance for jobs that require one.
That's far too low if those are current USD figures; you're hurting your and others' incomes by working too cheaply in a niché field. I was making $280k TC as a Rubyist at Meta or $10k/week consulting 10 years ago. That's not anywhere near as niché as Erlang/Elixir/Phoenix, OCaml, embedded Haskell, or embedded Rust. Or COBOL. ;o)
It’s purely remote and super chill. Not everyone wants to work on ads/compete with Indians/Chinese. I’d rather make 200k helping clinicians be more efficient using ML than $300k+ optimizing two tower models to increase the CTR on ads.
Hey there to all the EPIC kids poking their head in this thread. Where did you all end up post-EPIC?
Went to a smaller company for a short time, than ended up at FAANGs.
Epic had some nice features and it was really cool working directly with nurses and doctors. But it has some churn issues and the software sucks to use, especially with Epic's insistence on "all software built in house". While a good marketing ploy, it results in reinventing crappier wheels.
as a long suffering user, it always seemed like an ancient enterprise app. Always have to log in through some horrible Citrix setup to use it too...
Feast your eyes on Caché Server Pages. Mumps on the web.
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI....
The layout being broken on mobile is totally on-brand.
The description of MUMPS always misses what working with it directly is actually like (at least for me). It feels more like a custom OS than a programming language. Code being stored alongside data so changes apply live in the system, writing schemas and indexes by hand, and the difficulties combining it with other standard programming tools make it a fairly unique experience in 2025.
Way back in the day, while bored at my SaaS MUMPS support job, I wrote a version of the 'artillery' game in MUMPS, complete with graphics and explosions. I still wish I had that code somewhere :)
I used to convert data from a mumps system to a cobol based one 30 years ago. Fun times
Related. Others?
A Case of the MUMPS (2007) - https://news.ycombinator.com/item?id=36268931 - June 2023 (109 comments)
M, or MUMPS is a procedural language with a built-in NoSQL database - https://news.ycombinator.com/item?id=19388048 - March 2019 (2 comments)
MUMPS - https://news.ycombinator.com/item?id=18936990 - Jan 2019 (6 comments)
Isn't There a Vaccine for MUMPS? - https://news.ycombinator.com/item?id=17898927 - Sept 2018 (2 comments)
Introduction to the Mumps Language (2017) [pdf] - https://news.ycombinator.com/item?id=16309237 - Feb 2018 (42 comments)
The Mumps Programming Language - https://news.ycombinator.com/item?id=13859961 - March 2017 (178 comments)
MUMPS Instance - https://news.ycombinator.com/item?id=13618649 - Feb 2017 (1 comment)
Ask HN: Encryption and Security in MUMPS - https://news.ycombinator.com/item?id=13542953 - Feb 2017 (4 comments)
50 year old NoSQL DB that is better than MongoDB - https://news.ycombinator.com/item?id=12791425 - Oct 2016 (2 comments)
MUMPS, the Archaic Health-Care Programming Language - https://news.ycombinator.com/item?id=9895311 - July 2015 (49 comments)
I am a MUMPS programmer – Ask me anything - https://news.ycombinator.com/item?id=6312391 - Sept 2013 (68 comments)
> First appeared 1966; 59 years ago
That's honestly impressive. Though I don't envy people who have to work on this stuff.
Looks like someone just got hired to work at Epic!
I just heard about it for the first time today on the Primeagen post where TJ mentioned his first job was at Epic where he used Mumps. I assume that is how this came about timing-wise.
https://youtu.be/_CwpzZ8AVio
Great hands on video with MUMPS: https://youtu.be/Ij9k7EQ5AZQ
This was the first programming language I got paid to code in. It really did look like line noise. Good times.
These kind of hierarchical / network database systems are what caused E.F. Codd to tear his hair out and write https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
Codd tore his hair out also about it becoming SQL.
I worked at Epic the EMR company that probably has written more lines of M than any other company. Their EMR suite is the most popular in the US. They have a very high ratio of testers to programmers and I always wondered if this is because their ancient M code base is very brittle.
Obligatory: https://thedailywtf.com/articles/a_case_of_the_mumps
> OPERATORS: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.
How do you even come up with this?
PSA: POSIX shells (bash etc) do the same thing for && and ||. `true || false && false; echo $?` will be 1, not 0, because it evaluates `true || false -> true; true && false -> false`, not `false && false -> false; true || false -> true`. Don't assume like I once did that they have precedence like they have in C etc :D
Because it's dead-simple to parse? Remember that not all machines back then had hardware call-stacks.
This approach is, arguably, more readable because it relies on a simple left-to-right evaluation. Programmers don't have to recall the complex, though often familiar, rules of operator precedence.
Would reverse Polish notation be just as easy to parse and interpret?
RPN is slightly easier to parse and interpret but more difficult for most humans to parse and interpret. This is the middle ground that most everyone can quickly and easily adapt to writing and reading but would still be efficient on most any system.
It’s definitely easier to parse, but you can use shunting yard to do operator precedence parsing using very little extra memory and no recursion. I feel like the language is just poorly designed.
To be charitable to its original designers, information was much less easily accessible in the 1960s than today-although the shunting yard algorithm had been published in the research literature in 1961, practitioners working 5-6 years later may plausibly have been unaware of it-it wasn’t like nowadays where they could easily discover it in Wikipedia or by asking an LLM.
Yeah, that's fair enough. I'm sure a lot of weird / bad language design choices can be chalked up to this (COBOL...). Now that C and Pascal derived languages have been around for a long time, even if you don't know about how parsers work, everyone knows that certain syntax / semantics are at least possible since they're the norm, and I suppose that wasn't the case back then.
I implemented the same in some of my programming languages. If you look into very generic mixfix operators in some languages like Agda, you'll realize that operator precedence is a mess and it feels so much better to get rid of it. Of course, it makes the language unusable as a mainstream language, but it makes so much more logical sense.
Who came up with math precedence? Why is multiplication done first?
The explanation that makes most sense to me is that it's mostly to avoid having to explicitly write out parentheses a lot of the time. Especially for things like polynomials, which are a bunch of multiplied terms added together, eg 3x+2y and not (3*x)+(2*y). And in polynomials you can even drop the explicit multiplication symbol, so it's much neater. And once you've done this for algebra now you have to do it for plain arithmetic as well to make it all match up, and 3*5+2*7 gives the same answer as evaluating the polynomial at 5,7
One could argue it's the logical way, as multiplication is introduced as repeated addition.
Smalltalk does the same thing!
It's easier to parse since you can process it in-order, makes for an easier single pass approach.
Simplicity of implementation?
Not just simplicity-the original implementation was for a very resource-constrained 1960s minicomputer, where a more complex implementation would have slowed the system down even more and left less memory for running the actual business application
Tell me you would have come up with a Pratt parser yourself (or even a parser generator).
I honestly prefer that over complex precedence rules.