Notes on the M language (also known as MUMPS, Massachusetts General Hospital Utility Multi-Programming System).
- Hacker News - Thread
- Modern Healthcare - Q&A
- Stack Overflow - Answer
In this AMA on Hacker News from 2013, a MUMPS programmer - quink - addresses a few interesting questions:
Who uses it?
I work at a bank, and our banking system (the system that keeps track of the balances in the accounts) is written in MUMPS -- probably because it dates back to the time when that was the shiny new programming language.
Epic Systems, Inc. - according to this 2015 interview with Judy Faulkner, CEO.
Is there something takes takes a saner language and emits MUMPS (e.g. MUMPS LLVM backend?)?
i.e. to abstract away the crazy?
It has been done. The most popular form of MUMPS out there, Caché ObjectScript is a superset of MUMPS, so all existing MUMPS code will run on Caché. But it adds a big bunch of things from error handling to better variable scope to classes to, I wish I was kidding, proper 'if'.
Something that's also been added (to GT.M as well, afaik), because it is so tightly integrated with its database, are tcommit, trollback and tstart as commands, which are strictly speaking database commands and not the kind of thing you'd expect to find in a programming language.
'if'. There's two different types of if constructs, and it's awful, the older one is with a dot syntax.
What's a dot syntax, you may ask? Well, for each level of the if you just prefix a dot:
Makes you want to stab your eyes out. Note also that the comments need to have a dot prefixed as well. That bit me before.
Is it possible to use Cache ObjectScript on GTM?
The only experience I've had with GT.M is playing with it a little bit on Debian - it's only an apt-get away. As far as I know, no, apart from the shared ANSI M featureset. They're pretty divergent.
How does it feel to be using NoSQL so old it came back into fashion? :-P
We have dozens if not in the low hundreds of SQL tables. So, while we do have a huge pile of legacy code not using SQL you can map your NoSQL data structures to SQL tables and you can also later on convert to a more efficient format that gives you bitmap indices and so on, while still using the global storage backend.
So, it may have been NoSQL until some point in the nineties and after that it was really NotOnlySQL.
There's something a bit therapeutic about seeing the indices, including bitmap indices, and all the data on disk in a format that's intuitive and usable for humans that you can use without going through SQL, but either by accessing it directly or through the built-in ORM system. You don't get that with PostgreSQL or MySQL, or conversely, MongoDB or CouchDB. It's both worlds. Sure, there's a lot of stuff from PostgreSQL that I would kill for - any volunteers? - but as a compromise between the two worlds it works quite well indeed.
Edit: Here's more info:
The awesomest points are the %ID pseudo-column, implicit joins, embedded SQL (which compiles SQL down to native MUMPS code, including cursors and all), near enough complete SQL-92 and DDL compliance. And the ORM stuff.
Would you actually recommend anyone learn MUMPS for any reason besides job reasons?
Is MUMPS a dead language?
Not quite. Languages don't "die" per se.
I think the most relevant bit is that it's [Cache] much cheaper than Oracle. And I've seen Caché do quite complex things quite quickly, like with all database systems it's up to your indices more than anything else.
The entire VA (VistA) and the DOD (AHLTA, CHCS) systems are still implemented in Mumps and will be for the foreseeable future, far from a dead language
Is rewriting legacy code difficult?
Ask me again in two or three decades, but our codebase is continuously being touched in all places and there is an ongoing drive to weed out legacy code all the time. But just on the side I've been able to get rid of about 30% of all the legacy code here without spending that much time on it at all mostly with the help of grep, in part because our system has now moved to being 100% web from a desktop client.