Can a Phoenix arise from the ashes of Mumps?

There’s a major problem that is growing increasingly critical in the Mumps application world: where are the new generation of developers going to come from to support what is a pretty massive legacy of applications? The US Dept of Veterans’ Affairs’ (VA) VistA Electronic Healthcare Record (EHR) is just one of a large number of healthcare applications that was written in Mumps and is supported and maintained by a dwindling number of developers who understand and/or enjoy using Mumps.  The sheer scale of VistA and its growing popularity as an Open Source EHR outside the VA means severe problems ahead if a way of injecting new blood into its development community cannot be figured out very soon.

Simultaneously, there’s always been a massive frustration amongst those who (like me) have “gotten” Mumps: nobody else in the IT industry has ever been able to “get it” at all.

In a recent presentation, Javascript guru Douglas Crockford suggested that people who manage to “get” monads (a programming pattern that has emerged from the functional programming world) unfortunately immediately lose the ability to explain them to anyone else. I think those of us who have “gotten” Mumps have suffered the same ailment: we’ve never been able to articulate what was the particular “je ne sais quoi” magic that captured our interest in Mumps to anyone in the wider IT industry.

Sadly, that magic became increasingly hidden underneath deficiencies that the wider IT industry have progressively picked upon in Mumps, for example:

  • an old-fashioned, unfashionable and limited language
  • legacy code that turns being arcane into an art-form and lacks any semblance of the kind of variable scoping that all modern developers would expect to see
  • a database that was seen as just plain weird, particularly during the 80s and 90s when RDBMS reigned supreme

I’ve covered many of the reasons for these perceived deficiencies in an earlier blog article, but understanding the reasons isn’t sufficient to encourage todays’ generation of developers to do anything other than avoid Mumps like the plague (pardon the pun).  If I’m honest, I’m sure if I was a few years younger and came across Mumps for the first time,  I’d feel exactly the same too: learning Mumps wouldn’t seem like a terribly smart career move.

Of course, if we’d been able to convincingly articulate just what it was that made Mumps special to the wider IT community, then we wouldn’t have a problem: young developers would be lining up to learn and use it, particularly at a time when jobs are in short supply and their generation are desperately seeking worthwhile purpose: what could be more worthwhile that applying your IT skills to healthcare instead of the frippery and superficiality of gaming and/or social media?  Instead, despite its worthiness, they give Mumps, and therefore healthcare, a wide berth.  Recent experiments by OSEHRA to train a new generation of Mumps developers have demonstrated zero retention rate from around 200 students.  The bottom line is that it’s a dead language.

There’s plenty who will say that the death of Mumps has been being predicted for as long as it’s been around and yet here we are, 30 years later, and it’s still there, alive and kicking.  Perhaps so, but the small number of new developers who join the Mumps development community is greatly exceeded by the number of existing Mumps developers who are leaving through retirement or, sadly, passing away, and it won’t be long before the situation genuinely becomes critical.

It’s fair to say that there have been lots of attempts in the past to remedy this situation, none of which have had anything other than a minor impact.

In the mid-to-late 1990s, InterSystems morphed their portfolio of acquired Mumps products into an object-oriented (OO) technology: Caché.  Whilst undoubtedly a commercially sensible and successful move for them, nevertheless it remains a comparatively little-known, niche product, certainly by comparison with the household names of Oracle, SQL Server, MySQL and the many new, well-known NoSQL databases such as MongoDB.  Furthermore, many of us saw a discontinuity between layering a formally-pre-defined class based object layer on top of the free-form, dynamic hierarchical database that sits inside every Mumps and Caché system.  It seemed to me that one of the best and most powerful features of the technology was being wasted and compromised by such an OO implementation.  If that wasn’t enough, anyone wanting to use Caché’s object database has to learn a special language: Caché ObjectScript.  This is essentially the Mumps language with some (in my opinion very ugly) additional syntax to provide it with its OO capabilities.   Adding such object capabilities has clearly not been enough to attract the attention of modern developers and let them forgive the other deficiencies of the underlying Mumps language.  Mind you, Caché not being an Open Source product hasn’t exactly helped either.  Anyway, the not insignificant technical and marketing efforts of InterSystems have failed to impress the new generation of developers: few I meet have even heard of Caché.

There is also no shortage of language bindings for Mumps: over the years, pretty much every modern language you can think of has had a binding of some sort created for it, allowing globals to be manipulated and routines to be invoked from that language.  Bringing globals and the portfolio of legacy code to practitioners of those languages has clearly been ineffective: the magic “je ne sais quoi” that I and others know to be there in Mumps clearly hasn’t been apparent to those practitioners despite these bindings making it available to them.

We’ve even had complete conversion tools, one of the more recent ones being a product that could convert legacy Mumps code to Java, and move the database to a relational database such as Oracle.  That has failed to create any impact either.

Meanwhile, I’ve developed numerous Open Source projects and made umpteen presentations to the wider IT community, showing off the NoSQL capabilities of the Mumps database.  Instead of being impressed that a Mumps database can behave simultaneously like BigTable, Neo4j and MongoDB and therefore worthy of further inspection, the usual reaction has been along the lines of “but I can already use BigTable, Neo4j or MongoDB if I want those behaviours”.  The fact that we’ve been able to do the equivalent thing for 3 decades with Mumps is a mere half-interesting piece of history as far as they are concerned.

I’ve seen two main camps emerge from this:

  • a hard-core of Mumps developers who are still convinced that, despite the odds and evidence to the contrary, it really is just a case of training lots of new students and that magic ingredient in Mumps will light a spark in them too: they believe that newbies just haven’t “got it” yet, and they believe there’s just not been enough publicity and marketing applied to the problem;
  • the majority (which includes the wider IT community who might just have heard of Mumps) who have concluded that it’s a lost cause and that the day has come to just put a bullet in the dying beast’s head and put it out of its misery.  Of course the unanswered question is: what you do with the man-centuries of legacy code that is running a large percentage of healthcare worldwide if you adopt this strategy?

All rather depressing, you’d therefore think, but before you, too, give up the cause, let me bring a glimmer of hope.

I now believe there’s a third way ahead, and it offers real potential.  It’s the result of some thinking, research and work I’ve been doing over the Christmas period and is the reason why I’ve been quiet in this blog for a while.  I’m now really excited about it.  I announced it at the WorldVistA Community Meeting in Sacramento last week and even had it being excitedly used and tested out by those who attended my EWD training class in the days before that meeting.

The thing that particularly excites me is that as a result of this work, I’ve finally been able to put my finger on exactly what it is in Mumps that fired my imagination and retained my interest in it as a database technology throughout my professional career, and I’ve been able to figure out how we can make that magic ingredient accessible to modern developers in their terms and in a way that they can “get”.  I think this has the potential to make modern developers willing and able to maintain and onwardly-develop the vast legacy of Mumps code, and might even spawn new interest in the Mumps database technology itself.  If I’m right, I believe there really is an opportunity for a re-generated Mumps to rise, phoenix-like, from the ashes of its original incarnation, this time in the hands and under the control of the new generation of developers.

If you’re thinking that all sounds too good to be true, then watch this space: all will be revealed in the next parts of this article.


  1. Steve Owen · · Reply

    Looking forward part II!

  2. tom cook · · Reply

    Looking forward to part two.

  3. Fully agree with Rob’s point here, and I’m very excited to follow and contribute to the Phoenix rising.

    Just want to make a clarification about the retention of students who have been exposed to the M language. In particular the point that Rob makes about 200 students. Having been closely involved in that effort, my humble opinion is that the lack of retention is not only to blame on the language itself (or to put it in Monthy Python terms: “M is not quite dead yet”).

    To the newcomer to M, there are a variety of little barriers that when aggregated lead to rapid lost of interest from newcomers. Among those barriers we have:

    1) Google for “MUMPS Tutorial” and compare the results to what you get with Google for “Python Tutorial”. This Google search is one of the first things that any person will do when trying to learn a new language. Not being able to land in a modern looking, tutorial that gives a 20-min engaging introduction to the language, is a quick way to miss many of the young developers who may get curious about the language.

    2) Lack of ubiquitous availability of the M compiler. The GT.M compiler, which is open source, can be installed in Linux, by using a script kindly provided by fisglobal. However, it is not part of any standard Linux distribution. It is not either available for Mac or Windows. I do like Linux as much as the next guy, but the reality is that young developers are not going to change their operating system, just to try another language.

    On the bright side, efforts are under way to tackle these two barriers.

    1) A M-Tutorial has been developed by students at Rensselaer Polytechnic Institute (RPI) and it is available at

    The source code is open, and it posted in Github at

    Granted, this is only one tutorial,… but it is a first needed step.

    A much more complete tutorials are available at the fisglobal site:

    It is just not caught in the list of results of a Google search for “MUMPS Tutorial”

    Posts about these efforts are among the most viewed blogs in

    2) With the very active participation of fisglobal, an effort is under way to add GT.M to as a package in the Debian Linux distribution. Once there, it will trickle down to Ubuntu, Mint, and all the other Debian-based Linux distributions. Linux user will be able to have an M compiler by just typing

    sudo apt-get install fis-gtm

    There is also ongoing work to port M to the ARM platform, in particular to the Raspberry Pi (and effort inspired by Rob’s vision as well), and there are efforts to port M to the Mac and Windows. Helpers will be very welcome to accelerate these efforts.

    3) Initiatives to teach M as a NoSQL database are also under way at College level. These activities have been reported as well in

    What we found in this courses is that introducing M side-by-side with other NoSQL databases, such as MongoDB and Neo4j is a much easier task, and help students to quickly appreciate the value of M as a hierarchical database.

    All that said.

    I’m with Rob,
    any third and forth option is worth considering and pursuing, because at the end, the reality is that there is a code base of millions of lines of code in M that is currently running healthcare, and we can’t simply afford to ignore that fact. We can’t either pretend that a quick migration to other languages and systems is affordable.

    let’s go on reading more about that Phoenix…

  4. where is the converter tool? please publish.

  5. If you mean NodeM, the Node.js gateway for GT.M, its author, David Wicksell, is in the process of getting it published. If you’re referring to the OO projection, I’ve already published it –

  6. Hello all. I have published NodeM on both my github site (
    and up on the Node.js package registry ( So installing NodeM is as easy as typing this command at a Linux shell prompt (assuming you have npm installed):
    npm install nodem
    There are installation instructions there as well. Thanks.

  7. It is JULY now.
    What has changed? Is the bright side any brighter? Chuck Hagel is going COMMERCIAL and the Gartner Study on Vista is circulating widely.

    Click to access gartner_functional_vista.pdf


  8. Rob, your vision of the tool to revive Mumps has gained a lot of interest in the IT community, from what I can tell. Your dedication to the eventual ewd.js product has surpassed what people in the Mumps community could think possible. And now it looks as though your product will enter the mainstream of IT Healthcare in one of the largest Mumps implementations in the world, via Sid and others. Bravo Rob, bravo.

  9. […] The fact of the matter is, a large number of legacy EHR systems, including the trusted VistaA EMR by The US Dept of Veterans’ Affairs’ (VA) use a database system unfamiliar to the new generation but nevertheless amenable to clinical workflows called Mumps (often abbreviated as just M). Mumps historically had all the versatilities of modern NoSQL databases that are gradually coming to the forefront such as mongoDB. Rob Tweed, the Director and co-founder of M/Gateway Developments Ltd attempts a reincarnation of M by introducing a javascript/Nodejs based connector called EWD.js […]

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: