Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it.
But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs.
The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.
In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.
My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.
I agree with your points about weak typing and coercion being prevalent. Having had direct negative experience with it across 3 of the 4 languages you named, I was prepared to marshal an argument about it most definitely being a source of bugs.
> it should be obvious that this is a historical treatise
It wasn’t obvious to me. Might I suggest amending it to make that more clear?
I do appreciate the tutorial and your commentary though, it gave me a new perspective on MUMPS.
APL / K / J (and friends) evaluate things "left-of-right" (could be thought of as "right-to-left"), that is 1+23-4 is parsed 1+(2(3-4)) - there is no operator precedence. It is weird at first, but refreshingly simple and effective once you manage to overcome indoctrination you received since elementary school.
Well maybe it's just the stuff I do but even if you do something like 'address + offset * scale'
I still want to group that to make it obvious
'address + (offset * scale)'
The former technically works but it's less obvious. And that's a dead simple example
'address + offset << scale' is notionally the same but << has a lower precedence in c than + so you get the opposite behaviour so it's better to just bracket it out of habit.
I never find that I'm adding 3 random numbers. I'm adding 2 random numbers to make a meaningful value, then adding another number so a lot of the time I do 'foo + (bar + baz)'
Maybe if you're into pure mathematics you have a different take, but in my experience it's often the case that you end up bracketing most mathmatical operations for readability anyway
I don't know mumps very well, but this seems pretty straightforward if you put the primer next to it, and I am troubled by your (common!) reaction to alien technology...
> Stringly typed with literally no other types? Uh…
like this example here; SQLite made this choice too. Everyone knows about SQLite by now, right?
All types are strings when the user types them in, whether you are talking source code text, or the patient's weight in kilograms. Pretending you can have other types is something the source code of your application (or the language your application is written in) does.
This is something that makes total sense when you are thinking about things the right way (whatever that means), so when something makes you go "uh" try inverting this equation, and ask yourself, in what way (or under what circumstances) would this decision make sense?
That sort of thinking will get you the right ideas to understand everything else in the software world, and make you less avoidant about filling in the gaps in your own abilities.
> It had some neat ideas
Has. Multiuser support is still almost nonexistent in mainstream programming (and just recently starting to actually show up in SQL implementations!). And besides SQL, the most popular language with global variables you've might have heard of is perl. Understanding these ideas is still in the future.
Putting the ideas in the past, and framing them with such harsh judgement -- especially the ideas like this that you don't fully understand yet -- keeps them out of your mind, and denies you access to what these ideas can do for you.
As an example: A lot of people make a "users" table in SQL for the users of their application. Of course most SQL implementations have "users" of their own, and have a robust implementation that is already there, and yet almost nobody uses it and chooses to make their own rather than learn how to use the one SQL gives them.
Now: SQL exfiltrations are only possible because of this, and when you fully understand why that is you'll probably never make another users table again.
> and some absolute nightmare fuel.
but nightmares? Seriously? There was nothing in that example code that I am going to have nightmares about. It seems very well thought out (unlike say, Python's). It's even Y2K compliant. There is even a few ideas in there I'm going to steal for my own parser.
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.
It has also a presence in the financial world (under brand name "InterSystems Caché"), though mainly as no-sql database until Java and other foreign wrappers stop being enough, and suddenly you're writing stored procedures (or at least their equivalent) in MUMPS
I can’t speak for other companies, but I worked at Epic for a few years (left last year), and indeed MUMPS is still their bread and butter. In fact, I had not even heard about ObjectScript until reading this thread.
A few years ago, they _did_ develop a TypeScript wrapper framework (which was transpiled down into MUMPS). They heavily encouraged newer application code to use this, but it never caught on, was quietly abandoned after a bit.
Internally, MUMPS was often criticized or laughed at, but I doubt it’s going anywhere anytime soon.
Thanks for this interesting insight. Since they are apparently using Intersystems backends, I thought that ObjectScript might be a consequent choice; from my perspective it is rather comparable to JavaScript, so the TypeScript idea might have been stronger, but on the other hand might cause issues with (dynamically typed) globals.
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...
Not having literal strings in the source code, I do need to get a capital “R” somewhere and the name of the system being “IRIS” in system variable $ZV makes that easy and terse. Apart from that one trick I think it’ll be more or less just fine.
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.
In case anyone is wondering why anyone should give a shit about this language, the relevance of MUMPS is that the largest market share holder of EHR systems is Epic, and their core database still runs on MUMPS.
You life, quite literally if you find yourself in a hospital, depends on MUMPS.
The second largest competitor, Cerner/Oracle Millenium, runs on MSFT SQL, and it's on life support. Last I heard, Oracle was looking to unload it.
Millennium has a streak of failed implementations lately, VA in the US, two here in Sweden. It is not just Millennium I believe health care providers are pretty bad at tech.
I don't know about the Sweden saga, but the VA saga is a deep rabbit hole. I helped build a dream team of companies at one point to fix part of this for another system at one point, and the integrator fell down under their own weight.
I thought I was going into informatics to write code. It's politics as far as the eye can see.
MUMPS’ bad reputation is totally unearned. Most examples online (the wiki page, the awful Case of the MUMPS article) are examples of MUMPS code from the 60s-70s when storage was a premium and enterprise-size programs had to fit in a handful of megabytes, so there was no room for readability.
MUMPS code is more readable than most languages, it’s very simple and procedural. And the ability to interact directly with durable data the same as you do local data is very nice. I don’t know why no modern languages try to do something similar.
Interacting with durable data storage is actually pretty common.
Perl is modern (-ish? Definitely modern compared to MUMPS) and had "tie" for database access forever [0]
Python's dbm interface also looks like a regular dict [1]. I am sure there are many others, I know we had one "magic dict" in one of my work projects.
It's just that transparent access has some limitations, like lack of transactions, unexpected latency, lack of strong types, inability to only change a single value.
It’s always useful to look at prior art and review capabilities we might have missed. Innovation can happen by mixing the “good parts” of different old ideas.
On the flipside, sometimes people forget why we ended up where we're at and re-invent the pre-SQL database, only for everyone to realize that was a bad idea and switch en masse to PostgreSQL.
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.
I protest the characterization of Smalltalk as legacy. Seeing Cedar mentioned was very cool - Cedar/Mesa along with Trellis/Owl were environments
I was very interested in during my late high school / early college days, though I had no access to either. I do have a lot of Trellis documentation lying around somewhere someone at DEC kindly sent me when I wrote them about it.
I remember when I got into programming, when the thing to use was basic on a TRS-80, a friend was showing me how MUMPS was as much better language than basic.
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.
> 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.
Those unfamiliar with M/MUMPS are not aware of some of the built in features that have not been adopted by other platforms.
M allows one to code in a very terse language (an artifact of only 2K RAM/ transient temporary memory) with so many abbreviations and short forms for intrinsic/builtin functions, variables, commands, and other things. A large number of string manipulation, mathematical, and logical functions with a form of string recognition matching (from SNOBOL) and type coercion/interpretation round out the basic expression evaluation system. Allowing variable names as valid values for any variable gives a way to create dynamic expressions and symbolic manipulation.
A fixed point numeric value with over 18 digits of accuracy means math on values over the national debt can be stored in a single variable. Lossy floating point systems of other computer languages are not acceptable to customers. Limits on strings of characters depend on implementations and have been only increasing over the years beyond megabytes. All of these are managed without applications dealing with pointer arithmetic, allocation, deallocation, and such schemes such as Rust, C++, require.
The decision to separate out I/O into a subsystem was very common at the time, with various kinds of devices providing a high level model of channels & streams that are all managed below the language implementation level. Tight limits and timing for input I/O and output I/O means no buffer overflow exploits. Character set management also keeps control over contents of strings.
Generally, M has follows the model of high level capabilities under a very simple language interface. Each command has a highly focused syntax.
Which is why permanent storage uses a dynamic sparse variable indexed by strings whose stored values are strings and is indicated using the caret ^ as the prefix to the variable name.
This approach removed the need for user level applications to track disk latency, disk buffers, asynchronous processes, etc. which were common at that time.
Interprocess communication and control using a hierarchical Locking mechanism is very flexible. This means coordinating by locking a high level entry in the hierarchy and allow other worker processes to lock lower in the hierarchy.
The 1977 standard used a system that prevents deadlock from occurring. Later M Standards broadened the tools available with incremental & decremental locking and now deadlock can happen.
Transaction Processing allows one to separate data updates in a transparent way so competing control flows can more intelligently change the system.
Basically, this allows a try-retry-commit-stop backtracking command flow similar to Prolog and declarative code.
Control flow also uses the parallel invocation command (JOB) and normal subroutine calls (DO), with parameter passing and function return values. Looping is unified by the FOR command. Exception processing and control flow avoid undefined behavior.
Dynamic variable lifetimes using KILL and the NEW commands and associative memory access to values of variables. Typed controlled run time evaluation of commands adds discipline beyond "eval" in other languages.
The language allows implementations to specify unique abilities to increase unique commercial subsystems while still being backward compatible. There are ways to invoke external code
which can enhance capabilities as well as tieing to SQL and other languages.
While not part of the standard, high performance and reliable database management with ability to automatically recover from power loss using internal logging and rebuild tools, and compressed B*-trees is necessary for any M system to be viable in the market.
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.
Quite agree.
Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it.
But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs.
The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.
In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.
My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.
Thanks for the reply!
I agree with your points about weak typing and coercion being prevalent. Having had direct negative experience with it across 3 of the 4 languages you named, I was prepared to marshal an argument about it most definitely being a source of bugs.
> it should be obvious that this is a historical treatise
It wasn’t obvious to me. Might I suggest amending it to make that more clear?
I do appreciate the tutorial and your commentary though, it gave me a new perspective on MUMPS.
> the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.
Is it a bad thing? Or is it different?
I literally spray brackets about because Im not sure of the precedence.
Explicit over implicit is generally regarded as a good thing. Why is there a blind spot when this comes to operator precedence?
APL / K / J (and friends) evaluate things "left-of-right" (could be thought of as "right-to-left"), that is 1+23-4 is parsed 1+(2(3-4)) - there is no operator precedence. It is weird at first, but refreshingly simple and effective once you manage to overcome indoctrination you received since elementary school.
Well maybe it's just the stuff I do but even if you do something like 'address + offset * scale'
I still want to group that to make it obvious 'address + (offset * scale)'
The former technically works but it's less obvious. And that's a dead simple example
'address + offset << scale' is notionally the same but << has a lower precedence in c than + so you get the opposite behaviour so it's better to just bracket it out of habit.
I never find that I'm adding 3 random numbers. I'm adding 2 random numbers to make a meaningful value, then adding another number so a lot of the time I do 'foo + (bar + baz)'
Maybe if you're into pure mathematics you have a different take, but in my experience it's often the case that you end up bracketing most mathmatical operations for readability anyway
> Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night
I don't know mumps very well, but this seems pretty straightforward if you put the primer next to it, and I am troubled by your (common!) reaction to alien technology...
> Stringly typed with literally no other types? Uh…
like this example here; SQLite made this choice too. Everyone knows about SQLite by now, right?
All types are strings when the user types them in, whether you are talking source code text, or the patient's weight in kilograms. Pretending you can have other types is something the source code of your application (or the language your application is written in) does.
This is something that makes total sense when you are thinking about things the right way (whatever that means), so when something makes you go "uh" try inverting this equation, and ask yourself, in what way (or under what circumstances) would this decision make sense?
That sort of thinking will get you the right ideas to understand everything else in the software world, and make you less avoidant about filling in the gaps in your own abilities.
> It had some neat ideas
Has. Multiuser support is still almost nonexistent in mainstream programming (and just recently starting to actually show up in SQL implementations!). And besides SQL, the most popular language with global variables you've might have heard of is perl. Understanding these ideas is still in the future.
Putting the ideas in the past, and framing them with such harsh judgement -- especially the ideas like this that you don't fully understand yet -- keeps them out of your mind, and denies you access to what these ideas can do for you.
As an example: A lot of people make a "users" table in SQL for the users of their application. Of course most SQL implementations have "users" of their own, and have a robust implementation that is already there, and yet almost nobody uses it and chooses to make their own rather than learn how to use the one SQL gives them.
Now: SQL exfiltrations are only possible because of this, and when you fully understand why that is you'll probably never make another users table again.
> and some absolute nightmare fuel.
but nightmares? Seriously? There was nothing in that example code that I am going to have nightmares about. It seems very well thought out (unlike say, Python's). It's even Y2K compliant. There is even a few ideas in there I'm going to steal for my own parser.
There is good stuff here; don't give up.
Already discussed here: https://news.ycombinator.com/item?id=48707444
I don’t think that’s the same discussion.
Strange it feels worse than both raw asm and apl.
which assembler? modern assemblers with macros are quite easy
I was hyperbolic somehow. It's just that people usually hate on asm.
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 interviewed at Epic in 2011. Got through a couple rounds - enough to see how weird and culty the place was.
I was alone in a room with one of my interviewers, who seemed pretty sharp. I asked him "do you like working here?"
He looked at me, glanced at the closed door, leaned forward and said in a low voice "nobody likes working here. If you have another option, take it."
I thanked him and left and I'm very glad I did.
It has also a presence in the financial world (under brand name "InterSystems Caché"), though mainly as no-sql database until Java and other foreign wrappers stop being enough, and suddenly you're writing stored procedures (or at least their equivalent) in MUMPS
That was very disappointing to read. We might be migrating from an old M system (Meditech Magic) to a new M system (Epic).
At least the front end is much more modern.
Do they really use MUMPS? Not something like ObjectScript?
I can’t speak for other companies, but I worked at Epic for a few years (left last year), and indeed MUMPS is still their bread and butter. In fact, I had not even heard about ObjectScript until reading this thread.
A few years ago, they _did_ develop a TypeScript wrapper framework (which was transpiled down into MUMPS). They heavily encouraged newer application code to use this, but it never caught on, was quietly abandoned after a bit.
Internally, MUMPS was often criticized or laughed at, but I doubt it’s going anywhere anytime soon.
Thanks for this interesting insight. Since they are apparently using Intersystems backends, I thought that ObjectScript might be a consequent choice; from my perspective it is rather comparable to JavaScript, so the TypeScript idea might have been stronger, but on the other hand might cause issues with (dynamically typed) globals.
Bad news! My medical co.uses EPIC! Scheissurger!
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...
How do you think your code would do in GT.M or Yottadb? I understand both are open source (vs Cache).
Not having literal strings in the source code, I do need to get a capital “R” somewhere and the name of the system being “IRIS” in system variable $ZV makes that easy and terse. Apart from that one trick I think it’ll be more or less just fine.
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.
In case anyone is wondering why anyone should give a shit about this language, the relevance of MUMPS is that the largest market share holder of EHR systems is Epic, and their core database still runs on MUMPS.
You life, quite literally if you find yourself in a hospital, depends on MUMPS.
The second largest competitor, Cerner/Oracle Millenium, runs on MSFT SQL, and it's on life support. Last I heard, Oracle was looking to unload it.
Millennium has a streak of failed implementations lately, VA in the US, two here in Sweden. It is not just Millennium I believe health care providers are pretty bad at tech.
I don't know about the Sweden saga, but the VA saga is a deep rabbit hole. I helped build a dream team of companies at one point to fix part of this for another system at one point, and the integrator fell down under their own weight.
I thought I was going into informatics to write code. It's politics as far as the eye can see.
There are several other EHRs that use MUMPS too.
>on life support
Intentional?
There are newer versions of M/MUMPS around and some of them are open-source such as YottaDB https://yottadb.com/ and Reference Standard M https://gitlab.com/Reference-Standard-M/rsm .
I've never been quite brave enough to try to build something with it.
The project is intentionally about the MUMPS 76 standard and its anniversary, see https://github.com/rochus-keller/MUMPS/blob/main/Readme.md.
Agreed, I just wanted to point out that it is still around!
MUMPS’ bad reputation is totally unearned. Most examples online (the wiki page, the awful Case of the MUMPS article) are examples of MUMPS code from the 60s-70s when storage was a premium and enterprise-size programs had to fit in a handful of megabytes, so there was no room for readability.
MUMPS code is more readable than most languages, it’s very simple and procedural. And the ability to interact directly with durable data the same as you do local data is very nice. I don’t know why no modern languages try to do something similar.
Interacting with durable data storage is actually pretty common.
Perl is modern (-ish? Definitely modern compared to MUMPS) and had "tie" for database access forever [0]
Python's dbm interface also looks like a regular dict [1]. I am sure there are many others, I know we had one "magic dict" in one of my work projects.
It's just that transparent access has some limitations, like lack of transactions, unexpected latency, lack of strong types, inability to only change a single value.
[0] https://perldoc.perl.org/DB_File#A-Simple-Example
[1] https://docs.python.org/3/library/dbm.html
You would love OpenEdge ABL.
ABL is structurally much closer to Oracle PL/SQL than to MUMPS.
It’s always useful to look at prior art and review capabilities we might have missed. Innovation can happen by mixing the “good parts” of different old ideas.
On the flipside, sometimes people forget why we ended up where we're at and re-invent the pre-SQL database, only for everyone to realize that was a bad idea and switch en masse to PostgreSQL.
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.
I protest the characterization of Smalltalk as legacy. Seeing Cedar mentioned was very cool - Cedar/Mesa along with Trellis/Owl were environments I was very interested in during my late high school / early college days, though I had no access to either. I do have a lot of Trellis documentation lying around somewhere someone at DEC kindly sent me when I wrote them about it.
I assume you mean this project: https://github.com/rochus-keller/Smalltalk/
It's about a Smalltalk-80 image from 1983.
Trellis/Owl had interesting ideas, though I spent more time with Modula-3.
I remember when I got into programming, when the thing to use was basic on a TRS-80, a friend was showing me how MUMPS was as much better language than basic.
Good times
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.
> 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?
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.
Those unfamiliar with M/MUMPS are not aware of some of the built in features that have not been adopted by other platforms.
M allows one to code in a very terse language (an artifact of only 2K RAM/ transient temporary memory) with so many abbreviations and short forms for intrinsic/builtin functions, variables, commands, and other things. A large number of string manipulation, mathematical, and logical functions with a form of string recognition matching (from SNOBOL) and type coercion/interpretation round out the basic expression evaluation system. Allowing variable names as valid values for any variable gives a way to create dynamic expressions and symbolic manipulation.
A fixed point numeric value with over 18 digits of accuracy means math on values over the national debt can be stored in a single variable. Lossy floating point systems of other computer languages are not acceptable to customers. Limits on strings of characters depend on implementations and have been only increasing over the years beyond megabytes. All of these are managed without applications dealing with pointer arithmetic, allocation, deallocation, and such schemes such as Rust, C++, require.
The decision to separate out I/O into a subsystem was very common at the time, with various kinds of devices providing a high level model of channels & streams that are all managed below the language implementation level. Tight limits and timing for input I/O and output I/O means no buffer overflow exploits. Character set management also keeps control over contents of strings.
Generally, M has follows the model of high level capabilities under a very simple language interface. Each command has a highly focused syntax.
Which is why permanent storage uses a dynamic sparse variable indexed by strings whose stored values are strings and is indicated using the caret ^ as the prefix to the variable name. This approach removed the need for user level applications to track disk latency, disk buffers, asynchronous processes, etc. which were common at that time.
Interprocess communication and control using a hierarchical Locking mechanism is very flexible. This means coordinating by locking a high level entry in the hierarchy and allow other worker processes to lock lower in the hierarchy.
The 1977 standard used a system that prevents deadlock from occurring. Later M Standards broadened the tools available with incremental & decremental locking and now deadlock can happen.
Transaction Processing allows one to separate data updates in a transparent way so competing control flows can more intelligently change the system. Basically, this allows a try-retry-commit-stop backtracking command flow similar to Prolog and declarative code.
Control flow also uses the parallel invocation command (JOB) and normal subroutine calls (DO), with parameter passing and function return values. Looping is unified by the FOR command. Exception processing and control flow avoid undefined behavior.
Dynamic variable lifetimes using KILL and the NEW commands and associative memory access to values of variables. Typed controlled run time evaluation of commands adds discipline beyond "eval" in other languages.
The language allows implementations to specify unique abilities to increase unique commercial subsystems while still being backward compatible. There are ways to invoke external code which can enhance capabilities as well as tieing to SQL and other languages.
While not part of the standard, high performance and reliable database management with ability to automatically recover from power loss using internal logging and rebuild tools, and compressed B*-trees is necessary for any M system to be viable in the market.
Did they really have to use KILL as the word to delete a variable? Especially as it's used in hospitals? KILL patient....?
No you don’t - you can abbreviate it to just ‘K’ or ‘k’.
You obviously never read doctors notes in the 70s. Black humour was de rigeur
Yes, but this was programmers, not doctors.
I mean I find it humourous, I just have visions of discussions about 'killing' patients.
[flagged]