Making Mumps Acceptable to the Mainstream

At the recent WorldVistA Community Meeting in Fairfax VA, I gave a presentation that aimed to synthesise many of the arguments and thoughts I’ve written about in these blog articles.  The presentation was titled “Making Mumps Acceptable to the Mainstream” and created quite a bit of debate at the conference.

I’d encourage all readers to click on the link above and read through the presentation slides.  It aims to:

  • understand the reasons for the many criticisms made about Mumps as a technology
  • explain why those criticisms are largely unfounded yet fatally damaging to a technology that dominates Healthcare IT, to the extent that attracting a new generation of developers is becoming increasingly difficult
  • present a way forward to reposition the Mumps database as a uniquely powerful technology that is as relevant today as it was when it was first developed
  • present the reasons why the Mumps database baby should not be thrown out with the bathwater, just because of flaws in a language that is both optional and easily replaced
  • explain why JavaScript turns out to be the ideal, modern alternative to the Mumps language
  • explain why the combination of JavaScript, Node.js and the Mumps database creates an extremely potent and powerful combination that can attract a new generation of much needed developers into a massive and extremely important industry – Healthcare IT – that is crying out for new ideas and skills for visualising and modernising its use of Big Data


  1. Mike O'Neill · · Reply

    Sorry that I didn’t make it to the VistA Community Meeting this time. I would have loved to hear your presentation and the resulting discussion.

    This approach seems like such a win for all concerned.

    Is there any issue with M and node.js code accessing the same set of Globals concurrently?

  2. Mike

    Many thanks for your comments – I’m glad you like the approach.

    Several Node.js processes accessing the same Globals concurrently is no different from several terminal/green-screen users doing so – both Cache and GT.M are designed for this. In fact it’s no different from the situation when using any of the Cache or GT.M web gateways (CSP, WebLink, m_apache).

    An alternative question, of course, would be what happens if multiple web/browser users access the same global simultaneously? In a stateless environment such as that presented by the ewdGateway2 platform, you can’t rely on locks to prevent 2 people changing the same patient record at the same time or booking the same appointment slot since a sequence of transactions for a user will be probably handled by different physical processes.

    One solution to this is optimistic locking – something that would have to be designed at the application level.

    Another,very nice and very cool option becomes available when you use web sockets – for example in the scheduling scenario, when one person makes an appointment in a clinic at a particular time, a websocket message can be sent to all schedulers to instantly update and allocate that slot in their UI simultaneously, so that it can’t be rebooked by anyone else – so the UI can be used to at least control many concurrency issues when websockets are deployed.


  3. Let me start by saying that I am one of “them” — I first heard of Mumps by reading “A Case of the MUMPS,” but my work for the past several years does involve Mumps. I am not a fan of the language. To be fair, the Case of MUMPS post does say things that are plainly wrong (that there are no declarations, for instance), things that are misleading (lines are important syntactic entities, but this can be worked around with anonymous DO blocks), and just insignificant (commands can be abbreviated, but if you don’t like that, then just don’t do it). However, it does hit some important points (lack of operator precedence). And there are other language problems it doesn’t mention at all (try passing a subtree of a local array to a tag — you either need to copy that subtree and pass the copy, or use indirection; or how about the way $TEST may get clobbered by calls to tags that contain IF commands (though confusingly not to calls to functions)).

    In part, perhaps, as a reaction to some of the old Mumps code I run into daily, I have a strong preference for statically and strongly typed languages. I’d much rather have the compiler inform me that I’ve made a dumb mistake than have it be an error thrown at runtime (if I’m lucky). Certainly in something as important as a medical database, I want the computer to be able to automatically find as many bugs as early as possible. (Javascript suffers from the same problem here)

    It sounds like you think the language has fixed its flaws, but I respectfully disagree (it certainly has improved, but not really enough to be a remotely pleasant language). I do agree however that, however good or bad the language may be now, working with it is infinitely more painful if you have to interface with or maintain older Mumps code. I realize the language itself is explicitly outside the scope of what you’re trying to talk about in this post, but I’d be interested in hearing your opinion about the state of the modern Mumps language.

    Now, to the database. Although here I must confess that by the time I’d heard of “NoSQL”, it was being overhyped, and I never looked into it in any detail. I agree that this really is the better side of Mumps. And it’s great to use directly for small, simple things. But I don’t think I would want to use it directly for large, complex databases. I think it’s too low level for that — you’d have to build something on top of it.

    Say you have some piece of patient information, and it’s stored under ^patient(patientid,”info”). You also want an index on this information so you can search it quickly, so you have something like ^infoindex(infovalue,patientid)=””. I hope when you update the information in the ^patient global you can update the index as part of the same atomic operation. It can be done with the Mumps database, but it isn’t automatic like it is in SQL. I admit to not knowing how the fashionable NoSQL databases handle this.

    Similarly to how I prefer strongly+statically typed languages, I don’t see the attraction of a schema-less database. If some code tries putting bad data into the database, I want that to be an error right then and there, so I know who the culprit is. I don’t want to try to track down the source of the bad data some time later when the consumer of the data runs into problems because the data isn’t what it expects. Certainly this too could be build on top of what Mumps provides you with as a base.

    All in all, I think raw access to Mumps globals is useful for smaller projects (hell, I have in the past found myself wanting something like a Mumps global in some hobby Python projects), but for a larger database I’d tend to prefer working with something higher level.

    But something like this definitely could bring in a large number of new developers, which was the stated goal. And if higher level abstractions are required on top of Mumps globals, those could be built within Javascript.

  4. @koorogi: I agree with you about being one of ‘them’, and I got to know about MUMPS through ‘A Case of MUMPS’ too! I also share your preference for strongly, statically-typed languages. A compiler that catches more bugs at compile time is always a good thing. I’ve not used MUMPS professionally, ever, but as a doctor, have a professional interest in healthcare IT from the other end, so to speak.

    @robtweed: Instead of (or along with) JS, would a strongly typed C++ binding to GT.M be as good or better? C++ has excellent compilers and is available for most (all?) systems. It’s also expressive enough for GT.M, with the caveat of course that idiomatically, it is a statically-typed language. The current C++ binding for GT.M seems to be writing MUMPS code in a C++ wrapper. As C++ has no single “native” DB interface, a GT.M to C++ binding should look like it’s exposing a native multi-dimensional associative array Container to C++, play along with the Standard Library, etc., enabling the entire application logic to be developed in C++. is this possible/helpful?

  5. I have yet to see another language, and I know a few of them quite well, be able to do something that I cannot do in MUMPS, regarding database management/access, not moving pixels around a screen for the entertainment industry or thoughtless ramblings in social media sites, heck I bet a new social media craze could be created with MUMPS.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: