
MUMPS, the Archaic Health-Care Programming Language - vezzy-fnord
http://motherboard.vice.com/read/meet-mumps-the-archaic-health-care-programming-language-that-predicted-big-data-2
======
asmithmd1
The hospital where my wife works just spent $1.2B (yes billion) on software
written in MUMPS

[https://www.bostonglobe.com/business/2015/05/31/partners-
lau...](https://www.bostonglobe.com/business/2015/05/31/partners-launches-
billion-electronic-health-records-system/oo4nJJW2rQyfWUWQlvydkK/story.html)

The company that provided the software is interesting:

[http://www.epic.com/](http://www.epic.com/)

Based in a suburb of Madison Wisconsin, founded in the mid 1970's by a grad
student who wrote some software for a local hospital. They grew organically by
word of mouth never spending on sales or marketing. They landed Johns Hopkins
as a client years ago and now Epic chooses which hospitals are allowed to
"invest" in their software. They hire young grads right out of college who
have never worked anywhere else - who find themselves trapped with completely
non-transferable skills. It is like this company evolved in complete isolation
from any outside influence on software development.

Of course it is typical enterprise software developed by waterfall method that
puts users last. My wife says the doctors are in open revolt. They have 1000's
of open change requests - some critical to patient safety. For example the
field to enter prescription instructions is only 64 characters. This is a
hospital that administers chemotherapy so the instructions are more
complicated than "take with food three times a day." The developer who got
assigned that ticket had the nerve to suggest using abbreviations instead of
making the change.

~~~
ch4s3
I do a bit of work with Epic as a 3rd party vendor, its interesting to say the
least. The UX is pretty bad, but an internal human factors group seems to be
gaining influence and decision making power in the organization. Its also odd
because even as an older company, most of their workforce is in their mid 20's
and early 30s, so change is coming eventually. That said, a bad Epic install
will absolutely bankrupt a hospital.

And not to be a pedant, but Epic's big break was with Kaiser, Hopkins came a
years or two later.

~~~
kylemhill
Most of their workforce has been in their mid 20's and early 30's for the last
decade or so; demographic-inspired change isn't coming because they have such
insanely high turnover.

------
rwmj
I wrote MUMPS for a system called COSTAR (this was in 1989 or 1990). It was
truly a terrible language. From what I've tried hard to forget: Everything is
abbreviated, single letter functions everywhere. The database is a giant
persistent hash table, accessed through programming language variables, with
no schema, types or type checking (keep in mind this is used to store _medical
data_ ). Everthing is global. There's virtually no structure in the language,
I think they had subroutines but IIRC there were no named parameters. Existing
programs were just unreadable spaghetti.

Edit: Not Co-Star, but COSTAR:
[https://en.wikipedia.org/wiki/Computer_Stored_Ambulatory_Rec...](https://en.wikipedia.org/wiki/Computer_Stored_Ambulatory_Record)

~~~
briandear
Yes, you can use just the first letter of a function name. It might as well
support Morse Code for all the good that does in terms of readability. I wish
I knew what MassGen was thinking when they thought that was a good idea. I
shutter when I think of having to use that language for mission critical
systems (or any system for that matter.)

~~~
SloopJon
Keep in mind that MUMPS started around the same time as Unix (a little before,
actually), so the same motivation for naming commands like cp, mv, and rm was
likely at play in allowing abbreviations: interactive use on remote terminals.

------
jrapdx3
MUMPS is a subject I've tried to study before but confess I didn't get very
far. For my purposes back in the 90's, PostgresQL was the best fit and it has
worked out well.

Meanwhile EHR systems have become a huge industry, but now having to catch up
is hard. Learning about VistA is mind-boggling in its scope and complexity,
and especially since it has been open-sourced for a long time. It's a point of
curiosity that it's not been discussed more than a little here and there in
the FOSS media.

So I appreciate the informative article, as it gives me some starting points
to explore this vast field. Might even give another stab at MUMPS, though it's
a hill to climb. However some of the open-source projects that grew out of (or
on top of) VistA offer some interesting ways of approaching it.

One project with immediate appeal to me is EWD.js, which is a node.js
javascript implementation of server and client via WebSockets, and a MUMPS DB
backend. Should be interesting to try out.
[http://gradvs1.mgateway.com/download/EWDjs.pdf](http://gradvs1.mgateway.com/download/EWDjs.pdf)

I could be wrong but it seems someone just starting out could find
opportunities in the field of health care computing. Given the political
thrust to have EHRs everywhere seems logical the field will grow.

Above all, the need for security expertise in the EHR domain is enormous and
will greatly expand in the next several years. The FOSS aspects might well
create openings for innovators with creative products and ideas to reduce the
cost burdens that high-priced EHRs have been contributing to health care
systems.

------
jacques_chester
I feel like this journalist was struggling to understand the nature of
different kinds of databases.

> _document-oriented databases (where different types of data are stored in
> one unified document instead of a bunch of tabular cells)_

There isn't one document, and typically documents aren't "unified" in the
sense of having an enforced schema.

> _columnar databases (where data is laid out in key-valued arrays)_

Er, no. Where data is laid out in columns, to speed up aggregate and
analytical operations.

> _(Confusingly, the NoSQL name corresponds to "not only SQL" rather than "no
> SQL.")_

Backronyms ahoy!

> _But the thing about abstraction in computer science, whether it 's a high-
> level virtual machine-based programming language like Java or a bare-bones
> Unix shell, is that it always has a cost._

So does hard-baking a single storage and access pattern, which is that you get
it wrong and have catastrophically slow access and aggregation times. A
relational database is a generalist, query optimisers are generally good at
guessing how best to traverse a normalised schema and the last time people
used "abstractions are too costly!" as a serious argument it was in the days
of rewriting desktop apps in assembler.

------
Novex
So our saas web app backend is written predominantly in Cache Objectscript,
which is one of the few remaining implementations of MUMPS. We use it on a day
to day basis, which I guess makes me a MUMPS developer.

As a programming language, it's a fairly standard procedural language. Cache
introduces the ability for scoped java-like classes over the top of the
standard procedural code and there's a SQL/ORM layer that at least allows a
definition for the giant persistent hash table. That being said, a bunch of
our code is in the legacy unscoped routines which is... interesting.

The two real downsides are the complete lack of libraries for it (imagine
having to allocate time to port DEFLATE as part of your developement
scheduling) and the fact that 20 years of schemaless, unvalidated, tightly
coupled data access leads to a boatload of weird bugs.

Feel free to AMA.

~~~
shaftoe
How well does Cache interoperate with other languages?

Is it wrapped up in a library and consumed from another language that handles
web requests/responses? Can you extend the Cache libraries by writing code in
another language (even C) and importing it through a FFI?

~~~
Novex
There are bindings for most of the common languages to access Cache
structures/functions (.Net, Java, Python, Perl, C/C++, Node.js) but not much
the other way around. The only native to call out from Objectscript is via a
low-level C interface.

At the moment we're solving the problem by calling out to a set of Golang
microservices from Cache over http.

Cache itself actually has web support baked in, either via early-00's PHP
style "echo directly down the pipe" or a newer MVC style framework they've
built, but sadly stopped developing. Our product team made the choice to
transition to their MVC style framework, another team built on ASP.Net so
there are options.

------
Yizahi
Relevant WTF post:
[http://thedailywtf.com/articles/A_Case_of_the_MUMPS](http://thedailywtf.com/articles/A_Case_of_the_MUMPS)

~~~
bshimmin
"OPERATORS: No precedence, executed left to right, parenthesize as desired.
2+3*10 yields 50."

Wow. I mean... why?

~~~
acveilleux
Tiny little interpreter on early mini computers. You save RAM by not having to
evaluate the whole expression.

------
cstross
And for a different but convergent take on the same approach to this problem
space, here's the Pick Operating System, which evolved for business
applications on minicomputers in the 1960s, along similar lines (global hash
table database, built-in language):

[https://en.wikipedia.org/wiki/Pick_operating_system](https://en.wikipedia.org/wiki/Pick_operating_system)

MUMPS can thus be seen as a member of a (loose) family of 1960s era systems.

------
ultimape
My sister works for a place using Mumps. I read the manual she let me borrow
and I decided I liked it better than the COBOL I was doing at the time.

Then I cried myself to sleep.

True story.

------
jwdunne
Funny this crops up. I've had to quickly get to grips with a somewhat related
subject: a human readable healthcare interchange format called HL7 v2 (v3 has,
somewhat rightfully, replaced the custom format with XML).

Here's an example:

MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5
EVN||200605290901||||200605290900
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260
GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH
AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^
POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F OBX|2|NM|^Body
Weight||79|kg^Kilogram^ISO+|||||F AL1|1||^ASPIRIN DG1|1||786.50^CHEST PAIN,
UNSPECIFIED^I9|||A

~~~
daigoba66
Who said that it is suppose to be human readable?

HL7 v2 is actually fairly nice as a data structure. It's really easy to parse,
compresses nicely, and is quite flexible in terms of schema. I'll grant you
that the standard message schemas are terrible, but the data structure is
elegant for what it needs to do.

~~~
FLUX-YOU
>It's really easy to parse, compresses nicely, and is quite flexible in terms
of schema

It fine in modern languages with good string parsing tools but if you have a
v2 parser using simpler techniques in something that's difficult to debug
with, it can be a nightmare when something goes slightly wrong. I'm not a fan
of how we did it, but it has worked for 95% of cases and was coded in 1999, so
I can't really complain all that much.

Part of the struggle is massaging message parses where a vendor is doing
something slightly differently (or very terribly, like adding the lab's
director on every fucking OBX segment as if the director will get fired mid-
HL7 message and we gotta know about it).

------
emitchell
Meditech runs on a variant of MUMPS: MAGIC (and its subsequent iterations).
MAGIC was also developed by one of the researchers that made MUMPS. It's the
only language I've come across that allows variable assignment during
arithmetic.

------
briandear
Kind of wild this article appears now. I just yesterday was talking with a
potential partner when they suddenly dropped MUMPS connectivity into the
requirements. My first thought was, "Oh sh--!" I have some basic MUMPs
knowledge but I certainly don't want to have my business depending on it!

~~~
ericcholis
Similar situation here, met with an associate who was trying to integrate with
MUMPS.

~~~
rgaber
And this issue with this is?

------
raarts
Earlier in life I ported MUMPS to the ATARI ST. I remember the syntax as being
a little weird compared to all other languages I knew at the time. The
persistence was a nice touch though, it allowed you work with data in a very
intuitive manner.

------
vskarine
MUMPS powers chunk of TD Ameritrade infrastructure. While sounds cool, this is
just as scary as knowing that COBOL powers chunk of other banks
infrastructures (Schwab, etc).

~~~
qznc
> In 2006 and 2012, Computerworld surveys found that over 60% of organizations
> used COBOL (more than C++ and Visual Basic .NET) and that for half of those,
> COBOL was used for the majority of their internal software.
> [https://en.wikipedia.org/wiki/COBOL#Legacy](https://en.wikipedia.org/wiki/COBOL#Legacy)

Also, COBOL got a spec update in 2014. It is not really a dead language.

------
woah
> MUMPS concepts (directly) underly two of the largest contemporary NoSQL
> tools: GT.M and InterSystems Caché.

Huh?

------
ndonnellan
And I still hear devs balk when I mention our (ehr) backend is written in
perl. PERL!

------
Immortalin
How does this compare to languages with built in databases such as prolog?

------
chris_wot
Anyone who said that mumps was eradicated is kidding themselves.

