Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Medicine Technology

MUMPS, the Programming Language For Healthcare 166

Posted by Soulskill from the an-infinite-loop-a-day-keeps-the-doctor-away dept.
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 discussion has been archived. No new comments can be posted.

MUMPS, the Programming Language For Healthcare More

MUMPS, the Programming Language For Healthcare

Comments Filter:

  • MUMPS, ancient and rarely used (Score:5, Interesting)

    by Sez Zero ( 586611 ) on Wednesday July 15, 2015 @09:51AM (#50116045) Journal
    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.

    • Re: (Score:3)

      by alci63 ( 1856480 )
      Well, Intersystem's Caché database is essentially the latest instance of MUMPS. It still used quite widely in Hospital systems...

    • Re:MUMPS, ancient and rarely used (Score:5, Funny)

      by Registered Coward v2 ( 447531 ) on Wednesday July 15, 2015 @10:00AM (#50116119)

      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.

      While MMR vaccine has pretty much eradicated MUMPS the anti-VAX crowd is big enough so that it still crops up in isolated populations.

      • Re: (Score:2)

        by Tipa ( 881911 )

        The Digital Equipment Corporation's VAX line was entirely compatible with MUMPS (https://en.wikipedia.org/wiki/MUMPS). I guess you could say that VAX did nothing to destroy MUMPS, and in fact, was instrumental in its spread, seeing how integral DEC computers were to the greater Boston-area industries in the 80s.

    • As mentioned in the article, it's still in use in VistA (https://en.wikipedia.org/wiki/VistA), which has its own interesting history - in that the source code was made available via a successful application for release under Freedom of Information Act and has subsequently entered the public domain.

      VistA still going strong, and a number of successful businesses are based on it.

      MUMPS (or M if you prefer) is a terrible language, but it's heartening to know that all the effort that went into VistA didn't

    • They said that about COBOL too. It's still very probably the most-used language for business applications - for very good reasons.

    • Re:MUMPS, ancient and rarely used (Score:4, Insightful)

      by nmb3000 ( 741169 ) on Wednesday July 15, 2015 @11:50AM (#50117083) Journal

      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 [thedailywtf.com]
      MUMPS Madness [thedailywtf.com]
      Revenge of MUMPS Madness! [thedailywtf.com]
      MUMPS [wikipedia.org]

      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.

      • https://medium.com/backchannel... [medium.com] This, as well, is a story about health care computer systems, which means it's 60% likely they're talking about 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.

        Absolutely the best description of the most dreaded PDP/11 infection ever., but I think there was some evil Perl miasma there too - hence the Zombie like undeadness.

      • Epic drives their staff into the ground but they are a pretty cool place to work. They have been moving to a web platform for their front end and use C# so unless you were going to be working as a Technical Services rep you probably would have had an opportunity to do cool stuff on their core developer team rather than work with M (the Tech Services folks do a lot of M programming)

    • Re: (Score:2)

      by LWATCDR ( 28044 )

      I do not know about the rarely used part but MUMPS has been around for a very long time.
      https://en.wikipedia.org/wiki/... [wikipedia.org] VistA can use MUMPS for the backend so it is probably still in pretty wide use.

    • It's a nasty language too. Some is just from the style of the programmers at the time too; lots of spaghetti code, very short variable names, lack of comments. But even with good programmers, the language basically needs a good redesign (or a first design). I know someone who used MUMPS programs to study program complexity.

      • I have seen 5 line Perl programs that could be re written into 30 line programs that are easier to follow than most of the older M code I have seen.

    • It is used for SunQuest, Soft and a number of other medical software platforms. Cache Systems is actually a pretty good platform.

  • MUMPS: are you kidding? (Score:5, Informative)

    by iTrawl ( 4142459 ) on Wednesday July 15, 2015 @09:52AM (#50116059)

    O [thedailywtf.com] M [thedailywtf.com] G [thedailywtf.com]

    • Re: (Score:2)

      by derfy ( 172944 )

      The instant I saw MUMPS, I was thinking, "Haven't I seen that before?"

      Yes. Yes, I have.

    • Re:MUMPS: are you kidding? (Score:5, Informative)

      by jthill ( 303417 ) on Wednesday July 15, 2015 @11:44AM (#50117029)

      I'm used to anti-{language,tool,method} screeds being ignorant braying in lieu of effort, but this . . . This isn't even remotely the worst of it, it's only that it's soundbite-able. That first link deserves the word "mindboggling". The list here starts out slow, easing you in to it gently. No, seriously..

      • CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.
      • COMMANDS: may be abbreviated to one letter, case-insensitive. Includes commands such as IF, ELSE, GOTO, WRITE, and XECUTE [which is my personal favorite, it allows arbitrary execution of code contained in a variable]
      • OPERATORS: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.
      • DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.
      • DECLARATIONS: NONE. Everything dynamically created on first reference.
      • LINES: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."
      • LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.
      • GLOBAL ARRAYS: arrays that start with a caret symbol. Stored on disk, available to all processes, persist when process terminates. This is M's main "database" mechanism.
      • This list isn't totally accurate and seems a bit sensationalized for the "screed" as you put it.
        A variant of the XECUTE command exists in most languages.
        Declarations exist as there is still the concept of "stack level", but are optional. Dynamically created variables are scoped to the current stack level.
        Lines ... Well, you can put a lot on one line. But you can also write the equivalent of C# curly braces and do multi-line.
        Many of the others are presented with a tone of "can you BELIEVE this shit??

        • Re: (Score:2)

          by jthill ( 303417 )
          Thank you. I had dailywtf as more reliable than that. The older I get, the more I see that starting out assuming any publicized outrage -- and the more outrageous the more certain -- is nothing more than hyped-up attention-seeking jackassery is the way to go.

  • Why? (Score:5, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday July 15, 2015 @09:54AM (#50116077) Homepage Journal

    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 [uni.edu] 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.

    • Hmm. That sounds almost like you're tracking relationships. Maybe you should use... (wait for it) A RELATIONAL DATABASE.

      Keep in mind that MUMPS [wikiwand.com] first appeared in 1966, so it isn't exactly new.

    • 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 [uni.edu] 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.

      The challenge isn't that you can't do the same thing with a newer type of database but converting all that data into the new one. That is expensive, time consuming and invariably winds up with the loss of 20% or so of the data. My general rule is 2-2-20 Costs twice as much as planned, takes twice as long as planned and you lose or screw up 20% of the data.

      • Re:Why? (Score:4, Interesting)

        by dmr001 ( 103373 ) on Wednesday July 15, 2015 @10:35AM (#50116337)
        As noted above, MUMPS (in the guise of Intersystems' Caché) is the database underlying both the VA's Vista and Epic Systems' Epic, which are probably the two leading large-scale EMR vendors on the planet. My 5 state hospital system uses the latter, having upgraded from a system that just handled part of one state and ran on top of Oracle and would regularly slow to a crawl. I don't know how much of Intersystem's marketing-speak to believe, but for a gigantic disparate database of branching nodes of something on the order of a million patients and all their chart notes, telemetry data for those who have been hospitalized, lab results and links out to everything from fetal heart tracings to MRI's, the thing is fast and seems to be close to bullet-proof. MUMPS itself is scary (to me, anyway) with its global variables and odd syntax, and I have a few bones to pick about the interface, but the database layer is really remarkable.

        • Re:Why? (Score:4, Interesting)

          by Apocryphos ( 1222870 ) on Wednesday July 15, 2015 @10:54AM (#50116493)
          Agreed. I worked for Epic for many years and while M was a lot to get used to, you DO get used to it. And it is amazing for certain tasks.

          Epic crushed a lot of competition by marketing a "fully integrated suite". All of the applications (there could be dozens) for a customer run off a single M database. Why wasn't the competition stronger? Many reasons, but one was because most competitors were using SQL and couldn't compete on performance.

          The big limitation of M is reporting. Epic solved that by running extracts to a SQL "reporting database" and hooking up off the shelf reporting tools.

    • Re: (Score:2)

      by geophile ( 16995 )

      So, basically, a NoSQL database.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        MUMPS originally had a sort of in-memory database layer (map > >). They then abstracted that so it could load chunks of the database on the fly from disk. Later, that became a separate product (forked?) known as Intersystems Caché, which billed itself as a post-relational database (read: pre-relational, hierarchical database). Caché at least added SQL-like language to the product so it could pretend to be an RDBMS... so it's not necessarily no-SQL, because they added SQL later, but it is no

    • You should have stopped reading the summary when it got to this:

      and like a billion different varieties of catheter.

      And like I love, like, when a 16 year old, like, writes articles about stuff, like, they don't fully understand, like now. like dude.

      • "And like I love, like, when a 16 year old, like, writes articles about stuff, like, they don't fully understand, like now. like dude".

        That's rather funny, in view of some of the comments here about MUMPS' technical features. Criticizing a programming language and database management system based on a few lines of remarks made by someone who may not know much about it either... doesn't make a lot of sense.

        What cuts a bit more ice with me is that MUMPS is still being used - by the people who are responsible

    • Re: (Score:2)

      by T.E.D. ( 34228 )

      So basically, nothing you can't have in perl today, with a relational database, and a table or two ...

      MUMPS was an ancient joke of a language back in the '70's when I started programming (40 years ago). But now you've managed to sell me on its benefits.

    • 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

      • Fast, simple and hierarchical : is that a bit like an LDAP? Out of curiosity, do people sometimes build a database application on LDAP? Then if you need to do some desktop or other LDAP-enabled software, for more traditional purpose of not having to log in again and manage permissions etc. you already know how to do it.

      • This is why systems written in MUMPS have great transaction throughput and the UIs are usually responsive, but running reports is a nightmare.

        It's not necessarily a nightmare; it depends on the flexibility of the reporting tool. I've pretty well given up on using the built-in reporting tool at work for the reports I'm asked to produce because the tool doesn't allow for making the sort of complex links between globals that the report needs (i.e., patients with a given diagnosis who are also on a given medication, and their most recent result from a specified lab test), while producing the data with a MUMPS routine is straightforward because of the

      • Not quite. In COS (Cache Objectscript) just a superset of M really, the whole point of the language is to manipulate the data. You have the best of both worlds - the ability to store data hierarchically as well as relationally at the same time. Just figure out what you want to do and add in the appropriate indexes and write reports off of that. Like anything else you have to PLAN what the Hell you want to build before you go off and build it.

        I have coded in MUMPS since it was on a PDP 11/84 called Digital S

      • This is why in Epic they extract to an SQL reporting database and you write your reports off that.

        Kind of interesting, because for analyses we turn to data warehousing techniques, wherein you flatten your relational database into a star schema so you can quickly aggregate millions of rows. So you can go

        MUMPS (for transactional throughput) -> normalized SQL (for custom reporting) -> denormalized SQL (for analysis)

      • so you write a data extract process and send the reportable data over to it in a daily batch...now you get your monthly reports like a pro using BO and Crystal :-)

    • Re: (Score:2)

      by Qzukk ( 229616 )

      nothing you can't have in perl today, with a relational database, and a table or two to track relationships between objects.

      Sure, and there have been written entire books and essays and algorithms [stackoverflow.com] on how to get your relational database to store and return a hierarchy. It reminds me of those highschool programming challenges where you implement a binary tree in a single array because why the fuck not?

      But instead, it's a whole new opportunity to create problems!

      Every language invented in the 60's was a whole

    • Re:Why? (Score:4, Interesting)

      by littlewink ( 996298 ) on Wednesday July 15, 2015 @02:00PM (#50118285)

      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.

      Except that MUMPS did it 30-40 years before such features were available in relational databases.

      And see Henry Baker on "Relational Databases", Comm. of the ACM 35,4 (April 1992), 16,18.:

      Why were relational databases such a Procrustean bed? Because organizations, budgets, products, etc., are hierarchical; hierarchies require transitive closures for their "explosions"; and transitive closures cannot be expressed within the classical Codd model using only a finite number of joins (I wrote a paper in 1971 discussing this problem). Perhaps this sounds like 20-20 hindsight, but most manufacturing databases of the late 1960's were of the "Bill of Materials" type, which today would be characterized as "object-oriented". Parts "explosions" and budgets "explosions" were the norm, and these databases could easily handle the complexity of large amounts of CAD-equivalent data. These databases could also respond quickly to "real-time" requests for information, because the data was readily accessible through pointers and hash tables--without performing "joins".

      I shudder to think about the large number of man-years that were devoted during the 1970's and 1980's to "optimizing" relational databases to the point where they could remotely compete in the marketplace. It is also a tribute to the power of the universities, that by teaching only relational databases, they could convince an entire generation of computer scientists that relational databases were more appropriate than "ad hoc" databases such as flat files and Bills of Materials.

      Computing history will consider the past 20 years as a kind of Dark Ages of commercial data processing in which the religious zealots of the Church of Relationalism managed to hold back progress until a Renaissance rediscovered the Greece and Rome of pointer-based databases. Database research has produced a number of good results, but the relational database is not one of them.

      Sincerely,

      Henry G. Baker, Ph.D.

    • The problem is the same with lots of old programs. No one has the budget to throw them all away and rewrite them again, and then convert all the data formats. At least with COBOL there are a lot of people who know that language and the language is not terrible, so it survives with good reason. But MUMPS has few programmers and is a nasty language.

    • Hierarchical databases are more efficient for healthcare....and most applications that have lots of real time I/O

  • Microsoft is about to release their RAD for healthcare, called Visual AIDS. MUMPS has got nothing on them.

  • Oh the pain... (Score:5, Interesting)

    by aethelrick ( 926305 ) on Wednesday July 15, 2015 @10:28AM (#50116281)
    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*

    • Re: (Score:2)

      by LF11 ( 18760 )
      I'm going to go out on a limb and guess that you were looking at the database structure itself and did not take the time to learn MUMPS well enough to really work with it.

      I've never worked with MUMPS, but your aggravation is quite familiar. 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.

      I'm not defending MUMPS in any way, but you should be aware of this if you ever attempt data conversion in the future. Often (not alw
      • There was no structure. There is no "database" the code _is_ the database. I learned enough MUMPS in order to understand what I was looking at and what I could see was a system (I use the term loosely) that was made up of a disparate bunch of arrays with no conventions, arbitrarily duplicated and messy with no design or plan in sight. I'm quite comfortable with object stores and I learn fast, love data and I revel new challenges. In the project in question we'd already successfully and happily integrated ar

      • IDL (Score:2)

        by tepples ( 727027 )

        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 [wikipedia.org]? At least then you could add means to import and export objects with JSON or something like that.

        • At least then you could add means to import and export objects with JSON or something like that.

          since when do you need an IDL to work with JSON?

  • MUMPS predates UNIX (Score:3)

    by Ian.Waring ( 591380 ) on Wednesday July 15, 2015 @10:41AM (#50116375) Homepage
    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

    • I've read about MUMPS, never programmed in it,

      you could have stopped right there, everything after it is nonsense

  • MUMPS is nothing special (Score:4, Interesting)

    by xaintly ( 4186447 ) on Wednesday July 15, 2015 @10:56AM (#50116517)

    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.

    • Your understanding of the language and Epic's environment is incorrect.

      For example, you can write while loops, it has a different implementation of variable scoping (things down the call stack can access anything declared by any level above but not vice versa), of course you can sort an array (in fact, it's sorted as it's built), of course you can search the hierarchy (extremely quickly, too) and of course you can create and use discrete objects.

      While Epic is built on Intersystems Cache, it does not u

    • 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 [youtube.com] whether it's "web scale" or like "piping your data to /dev/null".

    • Re: (Score:2)

      by sfcat ( 872532 )

      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.

      MongoDB is not ACID compliant. Makes it a non-starter for something in the medical field.

  • Mumps usage (Score:4, Informative)

    by kcokane ( 253536 ) on Wednesday July 15, 2015 @11:01AM (#50116579) Homepage

    /. 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.

    • "/. comments seem to be a contest to see who can demonstrate the least knowledge of the subject".

      Exactly. And the competition is white hot.

  • I was part of the MUMPS community back in the 1970s and was the principal author of several documents that provided an executable specification of the language syntax and a guide to implementing globals efficiently, given the systems of that era. (I didn't write any MUMPS code that found its way into production.)

    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. Earl

    • 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.

      Do you spend a lot of time being appalled? Many languages have this capability, including SQL and the C variants.

  • 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 t

  • 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.

  • 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 hi

    • There is nothing a hierarchical database can do that relational databases don't do better.

      That's rather absolute. It seems performance is an area that hierarchical can be better, at least in certain use cases:

      http://www.intersystems.com/assets/datamart_wp-ee478edf530b40311ef506615c0da74d.pdf [intersystems.com]

      Conclusion
      In tests simulating a data analysis application typical for a telecommunications software firm, Caché was 41% faster than Oracle when creating a data mart of mobile phone information. When the resulting data mart was queried using SQL, Caché’s response times ranged from 1.8 to

      • Re: (Score:2)

        by msobkow ( 48369 )

        MUMPS does not let you deploy a clustered database server as Oracle does, nor any of the other major RDBMS vendors, so it's scalability is limited to how big a single node can be. Also, shoehorning Oracle onto a 4GB node is kind of a joke. I use as much memory for a laptop.

        I also see no mention of client-server deployment, with separate application servers. That is another implied limitations of MUMPS -- not only are you restricted to one database server, your applications have to run on that same ser

        • Yet Epic uses a single node per customer for all but a handful of its customers (Kaiser), and runs all of the customer's applications off that one server. The fact that they were able to do this was a major selling point, not a "limitation".

          For Kaiser, they set up logical geographic nodes and built their own sync system to update the network of nodes on demand.

        • perhaps you might want to actually read the documentation for the current shipping product before you make indefensible statements

  • Comments from a former MUMPS programmer (Score:5, Informative)

    by lurker412 ( 706164 ) on Wednesday July 15, 2015 @11:24AM (#50116801)
    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.

  • 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.

  • 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 aw

  • 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

  • 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="R

  • Holding things back... (Score:3)

    by ndykman ( 659315 ) on Wednesday July 15, 2015 @02:49PM (#50118729)

    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.

  • 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.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close