MUMPS, the Programming Language For Healthcare

citadrianne writes: An ICU patient is monitored and assessed according to 12 different variables. These include such measurements as body temperature, heart rate, blood oxygenation, blood pH, and others. Together, they're used to formulate a quantitative answer to the question, "How bad is it, doc?" Many of these physiological signs are measured in real-time via electrodes and like a billion different varieties of catheter. Add to it barrages of lab tests done multiple times per day per patient and the need for 20 or so clinicians (per patient) to have access to all of this data, and the result is very a deep data problem. Multiply that data problem by hundreds of thousands of patients.

This is the fundamental problem that the programming language MUMPS (sometimes called just "M"), or the Massachusetts General Hospital Utility Multi-Programming System, aims to solve. To its proponents, MUMPS allows for a one of a kind synthesis of programming and database management, while to to its detractors, it's a bizarre anachronism with little connection to the evolution and innovation taking place elsewhere in programming. Probably to most people that do things with computers, MUMPS/M is poorly understood, at best, and more likely to be completely unknown.

Comments

Why?

[drinkypoo]

Maybe it made sense once. But reading TFA, what convinced me that MUMPS is really BOLLOCKS was this quote:

For one thing, as a programmer, I can take an item stored in one of those globals and give it "children," which might be some additional properties of that item. So, we wind up with lists of different things that can be described and added to in different ways on the fly.

Hmm. That sounds almost like you're tracking relationships. Maybe you should use... (wait for it) A RELATIONAL DATABASE. Seriously, we often store object databases in relational databases. It's easy to add more properties to objects in your database with a relational db because of its very nature. You just create a new relationship, appropriately keyed. And there are lots of examples of systems backed by relational databases which permit you to add arbitrary new properties to objects. Take Drupal, for example; you can always either add a new module which will add new properties to old node types, or just add more data types to old node types. You could add, for example, a parent-child relationship. In fact, modules exist to do this already.

Maybe there is something about MUMPS which makes sense, but if there is, it wasn't articulated in this article. I tunneled down to the MUMPS/II page and found this:

1. Hierarchical database facility. Mumps data sets are not only organized along traditional sequential and direct access methods, but also as trees whose data nodes can addressed as path descriptions in a manner which is easy for a novice programmer to master in a relatively short time;
2. Flexible and powerful string manipulation facilities. Mumps built-in string manipulation operators and functions provide programmers with access to efficient means to accomplish complex string manipulation and pattern matching operations.

So basically, nothing you can't have in perl today, with a relational database, and a table or two to track relationships between objects. But instead, it's a whole new opportunity to create problems! MUMPS is a great name for it.

Re:MUMPS, ancient and rarely used

[nmb3000]

I have a doctor friend who, before becoming a doctor, was a CS grad. He's in his 50's now. When I told him we hired someone from Epic Systems that knew MUMPS, he exclaimed, "They still use that?! MUMPS was going out of style back when I was an undergrad!"

Yep, and MUMPS is still used at Epic, though they call it M and claim to have made customizations and improvements to it. I was offered a job there a few years ago and they go to great expense to attract recent graduates with high starting pay (more than $84,000 in Wisconsin), unbeatable benefits including the most amazing health care plan I've seen, and a pretty cool campus.

Unfortunately it wasn't enough for me to overcome moving to Madison, working long hours, and (most importantly) becoming an expert in an all-but-dead language. When I investigated career paths at the time, the only path MUMPS offers appeared to be (1) work at Epic for a couple of years and then (2) consult for Epic's products for the rest of your career.

If you want to see the very worst 1966 has to offer today:

A Case of the MUMPS
MUMPS Madness
Revenge of MUMPS Madness!
MUMPS

It's kind of like the worst parts of COBOL, Javascript and PHP were all mixed together and then baked at 400* until charred and smoking.