Slashdot Mirror
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.
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.
So rather than calling it MGHUMS, you called it MUMPS! Genius!!!
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!"
I believe it is also still used in older banking/financial tools.
O M G
"Everybody's naked underneath" -- The Doctor
doesn't the VA use this?
Artificial Intelligent Doctor Service or AIDS
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I first heard of a MUMPS language on Vax/VMS in the early 1990's. It seemed to be associated with lab environments. I find it hard to believe that hospital requirements are so unique as to not be addressable by a general purpose language like C++.
You know, they've had a vaccine for MUMPS for a long time but those anti-vaxxers are apparently bringing it back!
AntiFA: An abbreviation for Anti First Amendment.
Just google MUMPS horror stories and you'll get an impressive list of all the ways in which MUMPS is horrible as a language... and then all the ways that MUMPS is 10x worse in practice because of how it's prone to horrible problems with structure and readibility. And then all the ways it's worse than that because everyone who has a choice programs in something else... which means MUMPS "programmers" are generally a bunch of halfwits who would be right at home implementing complex business applications in excel spreadsheet macros.
If it wasn't for the sad fact that a lot of hospitals adopted it a few decades ago, it would have been left in the wastebin of programming history to which it rightfully belongs.
> 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.
This is not a matter of the language. The S in MUMPS stands for System. A System is a collection of concepts that can be implemented in any turing complete language. The ideas behind the system are the important things.
When discussing stupid/nasty/unpleasant programming languages, INTERCAL and Brainf*ck typically come up. However, both of those are artificial languages designed to be unpleasant. They are jokes.
I wish MUMPS was a joke.
MUMPS makes both APL and BAFLL seem sensible. The classic DailyWTF article, A Case of the MUMPS, really explains it all. Including things like an 8 character function name limit (even C fixed that, although not before we got the "creat" system call).
MUMPS is just as bad as it sounds.
MUMPS has many odd things about it. Evaluation is strictly left-to-right, so 1 + 2 * 3 evaluates to 9. There are 26 reserved words in the language, each of which begins with a different letter of the alphabet. In the old days, to conserve memory, it was allowed and encouraged to abbreviate each reserved word down to the first letter. There are essentially two scopes: "global", which means persistent, on disk, and "local", which everyone else would call "global".
Microsoft is about to release their RAD for healthcare, called Visual AIDS. MUMPS has got nothing on them.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
I was unlucky enough to have to advise how best to integrate a cobbled-together creaking MUMPS system into a more modern healthcare environment where the business wanted to "use SQL" to write reports against the data in the MUMPS system... of course the ancients who wrote the MUMPS system had done so with a complete disregard for maintenance and extensibility. NOTHING in the system was well thought out... in fact it looked a lot like a bunch of programming novices had just added a crap-ton of data in attribute/value pairs in no particular structure over a period spanning many years with each individual change being in complete isolation because the authors did not understand what had gone on before. It was also sadly really easy to copy/paste vast tracts of code along with the persistent storage bit so guess what the novices I mentioned earlier did? Yup, they copied and pasted a bunch. Now while this distasteful in any language, consider how much this hurts when it's in effect your actual data storage you're copying and pasting along with the code Furthermore... the authors had used every shorthand short-cut in the book because they hated typing (and the reader apparently). I can honestly say I'd rather debug befunge in my head than work with anything remotely related to MUMPS, M or Cache every again. From what I saw, the system was a write-once/read-never data soup that had no place in the GP practice management software that had been written in it. The system held fairly small amounts of data in bloody idiotic structures that were impossible to read without writing more MUMPS. All the business was trying to do with it was print a few letters and government forms... something ANY SQL database along with a report writer would have handled in a much simpler, cheaper and more maintainable manner. *shudder*
When I joined DEC as a trainee programmer in 1976, MUMPS-11 was one of the OS choices on the PDP-11. One of the guys still Product Managing high end systems at HP UK was a MUMPs support guy in Software Services at the time. Last saw it in the flesh as VAX DSM (Digital Standard MUMPS) back in the late 1980's. A lot of the revolutionary stuff like NoSQL and JSON type databases are just reincarnated from DEC way back when.
I do systems integration work, and most of the companies I work with are airlines or somehow connected with air transportation. Besides banks, airlines were the first companies to computerize, and a lot of that legacy is still baked into modern systems.
I've read about MUMPS, never programmed in it, but I see huge parallels in my work. The language was written back when every single byte of memory was expensive, hence the need for single character keywords. Airline systems were built out at a time when every single byte of data transferred over a comm link was super expensive. This is why an experienced reservation agent can complete a flight booking in about a minute if they know all the parameters -- the command language they use on most res systems is extremely terse.
The other thing is that most industries outside of legacy-land don't have literally man-decades worth of prior systems work to support. Everything user-facing these days (kiosks, airline web sites, etc.) is built on a framework of message-passing to mainframes at one level or another. And it must work and continue to work. Your average Node.js coder has no such limitations -- they just open up an AWS account, take a database server here, a web server here, slap some glue code together, and presto...iPhone app! It gets way harder when your bottleneck is something that just can't be fixed because it needs to continue working that way, because 1000 other systems are depending on that component to stay the same.
I can definitely see MUMPS being something like that -- horrible to work with but nearly impossible to replace with something modern. You can't just swap out a mainframe if your availability or I/O requirements don't allow you to use anything else, for example. Most legacy stuff can and does have some of the components replaced or abstracted away, such as terminal session management or data access for chunks of the application that don't require the power or availability of the underlying mainframe. Maybe the main thing driving MUMPS still is that in-memory database paradigm they support or just the sheer volume of business logic that would have to be rewritten to work with a regular DBMS. Either way, I wouldn't want to be forced to program in it. Go download the source code for the VA's Vista system, written entirely in MUMPS. It made my brain hurt.
"MUMPS/M is poorly understood, at best, and more likely to be completely unknown."
because anything with a single letter name is pretty much impossible to google (R anyone ?)
and mumps is an overloaded term in the medical namespace so its going to give a lot of false positives
I'm all for humourous names but you need to make sure they don't conflict or confuse first
[site]
MUMPS is only used in healthcare/financial systems because those institutions developed applications in the 1970s and are still maintaining them. There is zero interest in MUMPS for any new development. At the time (the 1970s), MUMPS offered a lot of features that other languages didn't. It is basically a hierarchical key/value datastore (like the windows registry, or a filesystem), coupled with a minimalist programming language (it still doesn't support 'while' loops, switch statements or variable scoping). There is no concept of relationships (except between layers of the hierarchy), no way to enforce datatypes, no way to sort an array, no way to search the hierarchy for anything, no way to create discrete objects or associate methods with data.
It does contain some advanced features (for the 1970s); multi-threading, distributed data, and the ability to abbreviate all language commands down to 1-2 letters so your program can fit into 4k of RAM.
EPIC, the medical records product used by many hospitals in the US, is built on top of Intersystems Caché. Caché adds relational features to the MUMPS database, object-ish features to the MUMPS language and supports SQL queries. Internally, it converts all queries to MUMPS, and you could totally bypass the API and write anything you like directly to the database (violating any constraints the API would have imposed on you).
If you are interested in schema-less/noSQL databases, I would suggest you have a look at MongoDB. It has all the features MUMPS does, but without the ancient programming language attached to it. It also has powerful searching capabilities, can store terabytes of data and supports transparent replication and distributed storage.
If you are interested in a schema-less database for a MEDICAL ENVIRONMENT, where accuracy matters and the difference between having a '12' in the dosage column vs. "123 any street, anytown, usa" (silently converted to 123 when treated as a number) could kill somebody, then please consider an alternate profession.
/. comments seem to be a contest to see who can demonstrate the least knowledge of the subject. While Mumps is largely unknown to many, it is widely used in health care and finance. Epic Systems controls about 40% of the US market (http://medicaleconomics.modernmedicine.com/medical-economics/content/tags/electronic-health-records/why-epics-market-dominance-could-stifle-ehr?page=full) and is written in Mumps as is the world's largest clinical information system, VISTA (http://worldvista.org/AboutVistA).
Mumps is a simple, string oriented scripting language for a builtin multi-dimensional and hierarchical database (http://www.cs.uni.edu/~okane/source/MUMPS-MDH/stonehill.pdf). It is especially well suited for applications such as medicine where knowledge is often as varying depth hierarchies that are not well suited for relational systems.
The commercial vendors are Intersystems (http://www.intersystems.com - their version is called Cache') and GT.M (http://www.fisglobal.com/products-technologyplatforms-gtm) whose version is open source / GPL. My own version (http://www.cs.uni.edu/~okane/) is also open source / GPL and can map the Mumps global arrays (the sparse array trees) to PostgreSQL.
Kevin O'Kane http://www.cs.uni.edu/~okane/
otherwise it would be a wonderful new Agile NOSQL database sytem.
MUMPS was initially developed for the 18-bit DEC PDP-7 in the late 1960's, where memory and disk constraints were severe, and processor speeds were a tiny fraction of today's slowest devices. Early MUMPS programs were limited to 1k characters, so every character counted, with most variables being 1 character long. Globals were done as a hierarchical "database", such as X(1,5,Z), again for space-saving and for efficient retrieval from the extremely small and slow disk drives of the day. MUMPS programs were interpreted, not compiled. With these constraints, comments were exceedingly rare, since they used part of the 1k, and slowed down the interpreter, which scanned every character.
As a computer scientist, I was appalled by certain features of the language, particularly the ability to change a running program by executing a variable. That's a security nightmare, since you could effectively read a string (stored as a global or input from the console) and then execute it as MUMPS code.
Here we are, more than 40 years later, and many of the major medical information systems are still running code that derives from the original flavor of MUMPS. Meditech and EPIC Systems are major vendors of medical information systems, including software for electronic health records, mostly developed in MUMPS. The much-overpraised VA electronic health record system is also MUMPS-based. As with any other production application, it's very difficult for a new vendor to come along and displace an incumbent, particularly if the conversion process is highly complex, as is the case here. As a result, there's no practical way to update these systems, other than rewriting them from scratch for modern languages and systems, something that is unlikely to happen anytime soon.
I've heard about MUMPS from it being used in Vista, the records system of the Veterans Affairs Administration, a large public domain corpus of software which was released from a FOIA request to the VA.
MUMPS is not a bad language. As with many languages, the source code readability depends on the programmers mostly, there isnt anything about MUMPS that makes it particularly hard to read. Intersystems Cache is one of the commercial implementations though it tends to downplay its MUMPS foundation, because of the false stigma around the language.
There are several Insurance Claims systems are built onto of MUMPS. If they are still active they almost certainly have Intersystems Caché running onto so that the data can be exposed to more modern stuff.
At least @david415 and @adr are anti-VMS. @willrad explains the joke.
HP/MPE had a hierarchical database, too. That OS and database have been dead for many years.
There is a good reason for that.
While I applaud the original poster's learning a bit about the bowels of computing history, the fact that they did so doesn't mean new systems should be developed with archaic tools like MUMPS. There is nothing a hierarchical database can do that relational databases don't do better. And as long as you're using one with ACID compliance, even a NoSQL database is better than a hierarchical system.
How, pray tell, is the ability to add attributes on the fly any different than "ALTER TABLE ADD COLUMN..."?
I do not fail; I succeed at finding out what does not work.
I used MUMPS (and MIIS) extensively while working in healthcare in the 80s and 90s. It was an efficient programming and database environment for mini-computers which combined a hierarchical database and interpreted language with sparse arrays and extensive pattern-matching capabilities baked in. It was widely used in hospitals for clinical operations and that legacy is still present in healthcare. The language itself would scare the shit out of anybody using modern technologies (self-modifying code, anyone?), but used with discipline it ran many applications that were literally a matter of life or death for patients. Some variants (MIIS, DEC) were also stand-alone operating systems running on the bare metal. It gave you lots of bang for the buck, even if the code itself looked like a printer test. There used to be a small but active community of vendors and users. Today, there is one large player, Epic Systems, which dominates the applications market, especially in the electronic medical records area. They use Intersystems MUMPS (now known as M) as the underlying language; it has an extensive application building environment on top of the basic language to provide relational, Web and object-oriented abstractions. You can build applications in this environment without ever touching MUMPS code, though commercial applications will generally drop down into MUMPS for special purpose routines.
Maybe you should use... (wait for it) A RELATIONAL DATABASE.
The advantage of a hierarchical versus relational database model is that the former is much faster storing large amounts of data that fits in the hierarchy (which healthcare data does). Foreign keys and hierarchical joins are built into the data. The disadvantage is that doing anything the doesn't fit the hierarchy is difficult compared to the flexibility of a relational model. This is why systems written in MUMPS have great transaction throughput and the UIs are usually responsive, but running reports is a nightmare.
As a former MUMPS programmer, yeah; it is bs. Modern languages do a better job in data management. However, certain health care systems do an EPIC job in pushing for obscure languages and technologies - like a message queuing database with a VB middle-ware layer to make it talk like a mainframe. Probably has something to do with lock-in and consulting... Yet, we have to push data into a relational data warehouse to do anything useful with it. SSIS and relational for the win.
In God we trust, all others require data.
Mumps? It sounds more like a disease than a programming language.
I worked for Quest Diagnostics and they used MUMPS. Cache is just the gift wrapping on the turd that is MUMPS. It's embarassing that our whole health care system depends on EPIC and MUMPS.
Fidelity Systems also has a MUMPS-based database called GT.M. It's open source (licensing is GPL+fuck up) and it's the main competitor to Intersystems Caché
https://en.wikipedia.org/wiki/...
how is this News?
many other healthcare systems are built on mumps, not just VA and EPIC. Notably Meditech is also mumps based, having rolled out of MGH the founders of MT took mumps with them. Judy Faulkner (from epic) then rolled it from MT created epic and drug around mumps with her. IDX (now GE) is also heavily into mumps. its everywhere. here she is talking about using mumps http://www.modernhealthcare.com/article/20150314/MAGAZINE/303149952
the new bread of healthcare apps have pretty much moved away from it.
It's what happens when you try to take apart a schema that is designed as an object store, without using the object accessing framework.
Shouldn't object stores be describable in some IDL? At least then you could add means to import and export objects with JSON or something like that.
because anything with a single letter name is pretty much impossible to google (R anyone ?)
I just tried two searches on Google (with queries r language and mumps language), and the top 10 results of both were relevant. What query was giving you trouble?
If you are interested in schema-less/noSQL databases, I would suggest you have a look at MongoDB. It has all the features MUMPS does, but without the ancient programming language attached to it.
But then you have to contend with rejected villagers from Animal Crossing arguing over whether it's "web scale" or like "piping your data to /dev/null".
I don't comment but, the VistA/CPRS system that runs the entire VA, leave/trouble tickets/etc..., is written in MUMPS and Delphi. So when they talk about interoperability with DOD or anyone you are dealing with an EMR that was cobbled together in the late seventies and eighties. By self taught government employees in MUMPS! So this is the 800lb Gorilla in the room with every project, I once asked when are we getting rid of this piece of @#$%, the stunned silence was deafening. No one in management has every been in any other hospital but the VA. None of the IT staff have a background in IT, or outside of the VA. So this is all they know, integration projects with new software is completed in months to years. So when you see a story about VA not being able to complete anything on time, this is the environment that they are operating in.
TL;DR: Think PASCAL for critical and wildly complex life-support systems; operating in the Internet age.
Having spent the last 10 years working in healthcare, I cannot overemphasize the ever growing cataclysm-to-be built upon MUMPS. One might then associate MUMPS the language with Mumps the disease (sans vaccine).
Worldwide, most major Electronic Health Records (EHR) systems are fundamentally based on MUMPS. Since the language largely predates all modern programming and system design principles like logic-data abstraction, imagine the mess created when various clinical applications (i.e. apps for pediatrics vs. oncology vs. pharmacy vs. radiology vs. geriatrics vs. etc.) are independently created and loosely cobbled together into a complex system - duplicative data representation and non-deterministic 'macro' processes/procedures are woefully common.
As cited in the Wikipedia MUMPS page, MUMPS is foundational to the largest EHRs (ref. Top 10 [US] EHR vendors by overall market share. In my opinion, this isn't so much because MUMPS is superior in anyway but because there really is 40+ years of codebase out there; much of it still in use today. Consider the US Indian Health Service (IHS) as example. For FY2014, IHS spent a total of $98M for IT. Although recognizing its own RPMS is hopelessly flawed, the agency estimates a capital investment >$150M and 15+ years to transition to newer technology. All the while, they must maintain and operate the current RPMS for ongoing healthcare delivery. Suffice to say and for the foreseeable future, IHS is hopelessly bound to the incumbent RPMS.
Meanwhile, "extensions" to MUMPS continue to proliferate. Since MUMPS heralds from the days of text-only dumb terminals, there is no in-language accommodation for graphical user interfaces and the common controls associated with event driven systems. This has led to many language extensions created for presentation 'wrapping' the underlying MUMPS output. And since MUMPS precedes modern design principles, newly minted programmers, admins and integrators must learn everything "from scratch" and, most often, in defiance/conflict of tenets they have been taught. Tenets and principles developed in response to hard lessons learned over the last 40 years of widespread IT experiences. These issues are exacerbated because those with the greatest experience are largely retired (or soon to be) and there are no significant opportunities for educating younger professionals except through other than "real life" - using live/production systems and actual persons' medical information.
dBASE (AKA "xBase") also integrated the programming language with the database, and I was super-productive under that language for a good many tasks. The bloated database API's used now are just eye and finger clutter and wasted busy-work and causes of Carpel Tunnel.
xBASE was not suited for formal "enterprise" applications or if you wanted fine control over the UI, but for smaller projects I could crank out apps in a snap. True, it was not always the easiest to maintain if not written carefully, but that's true with just about anything.
At least if you had to reinvent the wheel, the reinvention process was quick. Reuse and DB brand swap-ability is over-rated if it costs too much up front to get it.
Maybe there is a middle ground somewhere between "modern" languages and data-oriented languages. I really really miss the productivity of the integration. I hope it comes back in some incarnation.
Table-ized A.I.
A group of rappers created the Programmers Utility Multipurpose Programming System And Non Determinant Allpurpose Binary Utility Multiprocessor Protocol, designed to encourage young women to go into the CS field.
One of its creators publicly stated that despite their (and the CS field in general's) misogynistic reputation, they actually liked the girls with the PUMPS AND A BUMP!
MUMPS criticism (Score:?)
by Anonymous Coward on Wednesday July 15, 2015 @01:55PM
MUMPS was designed as an extremely robust language language for programming life-and-death software.
MUMPS critics can be divided into two categories:
1) Those who say, "MUMPS has GLOBAL variables. Arrgh."
2) Those who say, "MUMPS is a '70s language which was ahead of its time. Maybe it is time to move on. There are companies which can move your MUMPS legacy system to modern databases and languages for $100,000.00."
If someone tells you that MUMPS is ruined by its dependence on globals does not know what they are talking about. MUMPS's Global Variables were names "global" before the term got its modern meaning. They are really more like what we call today "persistent variables." They are instrumental to a fundamental property of a good MUMPS program: the ability to maintain state through a pull-the-plug-out-of-the-wall type of crash.
Yes, it is possible to misuse persistent variables in much the same way that you can misuse xBase globals. But MUMPS makes it easy to avoid that. And hard to DO it.
I work in an environment with a MUMPS back-end maintained by people who have no idea how to maintain it. Despite this, the back-end is the most reliable part of our IT operation. (For MUMPS programmers: These guys are trying to maintain a VistA-based system, heavily modified, without using M-unit.)
I once described MUMPS to an object-oriented programmer like this, "Its data structures are essentially structs and it has the lambda function."
He replied, "Then it has objects." I understood what he was saying, but it was invented in the 1970s, before the concept of OOP had even been invented.
I thought it was fairly well known just as a horror story about what happens when you don't design a language, you just accrete it (charitably, when the language is extended so far beyond the initial design that it completely escapes it). Like bash or perl or PHO but oh so much worse because everything's worse in health care and govt.
From Wiki, this is considered good MUMPS code:
GREPTHIS()
NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
IF IF=THEN DO THEN
QUIT:$QUIT QUIT QUIT ; (quit)
THEN IF IF,SET&KILL SET SET=SET+KILL QUIT
But in practice it looks like:
%DTC ;1/16/92 11:36 AM ;;19.0;VA FileMan;;Jul 14, 1992
%DTC ; SF/XAK - DATE/TIME OPERATIONS
D I 'X1!'X2 S X="" Q
S X=X1 D H S X1=%H,X=X2,X2=%Y+1 D H S X=X1-%H,%Y=%Y+1&X2
K %H,X1,X2 Q
;
C S X=X1 Q:'X D H S %H=%H+X2 D YMD S:$P(X1,".",2) X=X_"."_$P(X1,".",2) K X1,X2 Q
S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q
;
H I X2&'(%Y#4)+$P("^31^59^90^120^151^181^212^243^273^304^334","^",%M)+%D
S %='%M!'%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-1,1:%H+4#7)
K %M,%D,% Q
;
DOW D H S Y=%Y K %H,%Y Q
DW D H S Y=%Y,X=$P("SUN^MON^TUES^WEDNES^THURS^FRI^SATUR","^",Y+1)_"DAY"
S:Y21608+%H-.1,%Y=%\365.25+141,%=%#365.25\1
S %D=%+306#(%Y#4=0+365)#153#61#31+1,%M=%-%D\29+1
S X=%Y_"00"+%M_"00"+%D Q
;
My first job out of grad school in 1981 was with the University of Wisconsin clinical cancer center. We built a DB to track clinical trial data. I was 1/2 the programming staff and we wrote the code in MUMPS running on a special purpose OS that ran on a Data General minicomputer. The base of our code was a DB-like program written by the VA and distributed all over. The OS was the truly terrible part. The disk was formatted into 1K blocks and these blocks were the closest things to files that it had. The blocks had names and were organized alphabetically. Programs that didn't fit in 1K had to be broken into multiple blocks, executed in a chain alphabetically. Mumps had some OK features like good string pattern matching and the array like structures were handy. Each array was the equivalent to a DB table and each row a tuple. No query language though. To effectively use the ridiculous 1K block structure, all reserved words were 1 character and so where all variable names. A legal statement was I I W W So, as others have said, just writable but un-readable. I gave a talk at a MUMPS conference and was one of very few trained programmers there. Most were medical professionals who did some coding. Some of the people who had worked on this project before me had gone off to form Epic Systems. I wouldn't want to code in it again, but it was a good job.
You knew the job was dangerous when you took it. -- Super Chicken
MUMPS and PICK (BASIC) are the grand-daddies of NoSQL. They are both very much alive today. I've been a PICK programmer since the late 90's. The schema-less structure of the database tables (and like MUMPS, it's a language & a database... and at one point it was also an O/S) is much easier to work with than SQL's relational structure. The data is not normalized and is more commonly known as "multivalue." More info here... https://en.wikipedia.org/wiki/...
It was used in many areas, police blotter, 911 dispatching, and police line up creation. Yes I worked on those systems using Intersystems Mumps on various platforms in the mid 90's. The language itself was relatively easy to pick up and learn, but it was a nightmare to support the older code. Spaghetti code is an understatement. Self modifying code, executing global variables as code, then add to that single letter commands, and you had a serious nightmare trying to debug anything you didn't write yourself. I remember several times where I just rewrote things from scratch just because it would be faster than me figuring out what some routine did then modifying what was there. I can say I am glad I don't use it anymore.
The main problem with the environment is that between Epic Systems and VistA (the VA system), MUMPS holds back some real innovation. Sure, you'll hear tons of success stories about the VA or from EPIC, but the fact is that this vendor lock has huge costs. A major hospital chain I worked with spent a billion+ on a EPIC implementation. Did it improve interoperability with other hospital systems? Nope. Even two EPIC implementations will have a very hard time sharing records.
And that's the whole point of a EMR, to have a consistent version of a patient's history throughout their life. And these systems can't support that model in our current system. If every doctor had to use one system (like in some national health care systems), it'd be better, but that's not what we have. Sadly, the other attempt to standardize healthcare systems and interoperability (HL7) is an equally convoluted mess.
What is needed (but we won't get because of the players) is a standards driven process that is focused on building up a workable ecosystem for exchanging information.
It'd be hard to create a standard that would allow for healthcare professionals to: provide proof that they are a provider and to provide electronic evidence that they have a patient (via a secure exchange) to create a unique identifier for that patient/provider, but it is doable. Solve that, then move on to exchanging of information between providers and allowing providers to mark information as not shareable to the patient or other providers. All of this could be done, and it would provide a real basis for a proper EMR system.
I first encounters MUMPS in 1994 while working for a major hospital in Cleveland. The company, HBOC used the language for their patient care software. The language is bit for those who believe that knowing C or other similar programming language that this will be easy. MUMPS USES SINGLE characters as instructions and is a throw back to assembler days. I tried following the one and only MUMPS programmer available, who was backlogged for months if not years with request for work and gave up. A capital 'J' might be a loss memory while a lower case 'j' something different.
I thought that the reason for the back log in work was because of the archaic language, and I laughed and went back to my own programming.
Healthcare will always be a mess until the industry moves at least into the 1970s and dumps the MUMPS.
This is some MUMPS i wrote for fun. I guess if you can analyze this, your tool works:
Oh, The joys of a shelf full of old computer books.
DEC transitioned MUMPS from the 18-bit line onto the PDP-11s. I think that the majority of Mumps systems were on the 11s and then moved to VAX as it came on the scene. I can find no mention in the PDP-8 books. If MUMPS was moved there it was not a standard DEC product. Likewise, the PDP-10 books don't cover MUMPS. I would assume that it was moved to the 36-bit machines, but have no reference. Does anyone out ther have some record of MUMPS on the PDP-10??
The DEC PDP-11 reference manual set had one volume on software systems for the PDP-11s.
I pulled the 1975 and 1980 versions.
DEC PDP-11 Software Handbook, Copyright 1975
Section II: PDP-11 Operating Systems
Chapter 1: Cassette Programming System CAPS-11
Chapter 2: Foreground/Background RT-11
Chapter 3: Resource Sharing Timesharing System RSTS/E
Chapter 4: Multi-user Database Managemetn System MUMPS-11
Chapter 5: RSX-11
Chapter 6: IAS
The intro to MUMPS describes it as: A small to large sized timesharing system that offers a unique fast access data storage and retrieval system for large database processing.
The MUMPS chapter is 26 pages long with a reasonable amount of reference detail for the time. The database aspect was the unique selling point.
By the 1980 version of the same DEC PDP-11 Software Handbook, MUMPS had moved to Chapter 8: Digital Standard MUMPS.
The intro section describes:
DSM-11 Digital Standard MUMPS operating system for PDP-11 processors.
A small to large sized timesharing system that offers a unique fast-access data storage and retrieval system for large data base processing. Originally designed for medical record management and now available for similar data base applications.
Chapter 8 of the 1980 Software Handbook has a more prose-like description than the reference-manual-like 1975 chapter. The new version has a good description of hospital medical record processing and claims over 500 major hospitals using MUMPS.
So it was under active development and use through the 70s on the PDP-11s.
With that base it is not surprising that MUMPS is still in use.
At first I thought it was a ridiculous anachronistic language developed by a bunch of IT guys in the 60's that had a poor understanding of even most contemporary ideas of programming languages. now? I think it has it's place. It is very focused on mutli-dimensional arrays and makes manipulating hierarchical data structures very efficient. Another person's Perl code is easier to read but it is efficient for what it does.
As I understand it, it's like Lua, except that variables aren't declared, and they're in a global namespace. And they're limited to 8 characters long. And if's and loops are limited to single lines (that are probably limited in turn to 80 or 60 characters - whatever their punched cards were eh?)
Basically unusable for large systems. But used for them anyway.
Any shop that's forced to use Mumps should write a compiler for a better language that outputs Mumps, and convert their Mumps code to that better language. It would take a much shorter time than maintaining Mumps code.
I came to MUMPS late in life (programming for 30 years in a dozen other languages before ever encountering it), but I like it just fine. The hierarchical database is very flexible to use and very disk space efficient compared to the standard relational model. Keep in mind that most relational databases get their "efficiency" by creating indexes, which are basically invisible extra tables containing cross-references into the visible tables. You can explicitly do that in MUMPS if you want to; it just doesn't happen "automatically".
Some problem domains just beg for a relational solution and some work well with a hierarchical solution. A good programmer's toolbox contains many tools.
The language is pretty cryptic, but no worse than several others from that era. You can write "good" programs in any language and you can write "bad" programs in any language. You learn the syntax and learn the semantics and then practice for a while. The language itself has some very powerful constructs that can make a programmer's life easier or harder. Likewise with the database that backs it up.
MUMPS today is primarily used in the medical world, but the European Space Agency also uses it extensively as do Credit Suisse and others in the financial world.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana