Introduction to the Mumps Language (2017) [pdf]
cs.uni.edu
cs.uni.edu
Wrote a simple web server with it for a VAX in 1999.
Loved how you saved data to disk. You just but a ^ in front of a variable declaration:
^myData
set ^myData("canada", "bc", "yyj") = counter
> Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read command, $TR = $Translate function. Spaces and end-of-line markers are significant in MUMPS because line scope promoted the same terse language design. Thus, a single line of program code could express, with few characters, an idea for which other programming languages could require 5 to 10 times as many characters. Abbreviation was a common feature of languages designed in this period (e.g., FOCAL-69, early BASICs such as Tiny BASIC, etc.). An unfortunate side effect of this, coupled with the early need to write minimalist code, was that MUMPS programmers routinely did not comment code and used extensive abbreviations. This meant that even an expert MUMPS programmer could not just skim through a page of code to see its function but would have to analyze it line by line.
https://en.wikipedia.org/wiki/MUMPS#Overview
I'll add that Wikipedia's take here is a little optimistic: perhaps it was true when MUMPS was invented that it could use one line to accomplish what would require "5 to 10 times as many characters" in other languages, but MUMPS's language constructs are by and large about as low level as assembly with a couple exceptions, so this is definitely no longer the case if we're comparing it to modern high level languages.
In addition to Epic, the US Department of Veterans Affairs wrote their homegrown EMR in MUMPS. Their development group is here: https://groups.google.com/forum/#!forum/hardhats
Eh, as someone who's used it professionally, I wouldn't compare it to assembly. It's more like Awk - fairly concise for a good deal of its intended uses (linewise text manipulation for Awk, trees for MUMPS) and horribly clunky for most everything else.
So why didn't they use a bytecode interpreter, or at least a minifier (as is done with JavaScript), so that the programmer could keep the source code readable while still giving the interpreter a compact version?
Would it have been too computationally expensive, or had people just not come up with the idea yet?
That makes me think of TECO, where a string of commands resembled transmission line noise more than anything resembling program code.
The most TECO that I ever learned was how to invoke VTEDIT, and I forgot that a long, long time ago. :)
I suspect we would keep using it, except, last I heard, HP off-shored their OpenVMS maintanance to India and declared, in like 2011, that it would be EOL'd in 2017.
edit: I retract the statement that it's running on a PDP-11, though I have to say I was told that in teleconference just last month. I remember because it was shocking.
2. OpenVMS is alive and well. It wasn't outsourced to India and it does not have EOL date. Currently it's being developed by VSI (https://www.vmssoftware.com/) and they're porting it to x86.
http://h41379.www4.hpe.com/openvms/openvms_supportchart.html
Bonus - perfectly valid Mumps code
P R I N T S (A,L)=1,(S,T)=I N G
G I V E N A
O F A=L:L:S Q:U=A R E S B=E L O W (A*A),!
I S (U,R,E)=T H 1 N K I T=S G O O DBut I can't say for sure that it's entirely the fault of MUMPS rather than the amateurs who wrote the code. It literally was amateurs; they were doctors and interns, not professional programmers. They made a system that fit their needs quite well at the time, so they deserve quite a bit of credit, even though their source code is a nightmare by modern standards. Their story is recounted in the book Best Care Anywhere.
Total cost approx. 2 billion euros majority going to Accenture and Epic Systems (which if you didn't read thedailywtf recommend checking out). The new medical system in Estonia cost about 5 millions I heard. It's just incomprehensible to me how they are going spend 400 times more money with 5x more population.
https://news.ycombinator.com/item?id=13859961
Does anyone know the story behind why these slides keep getting updated? Is this a databases class?
> Caution: Not recommended for moonbats, liberals, Clinton drones or Bernie’s Sandernistas.
as an aside, there were some positive notes, as it was my first real introduction to a noSQL database (Caché) in a professional setting, 2006.
Very good language if unmaintainable, arcane code and/or job security through obscurity is your thing. Cache even let it onto the web some years back I think with ObjectScript. Just wholly nasty. The politics in medical software has been pretty rife from what I've experienced too.
I know one or two MUMPs people. They're deeply, deeply odd.
The Mumps programming language is widely used in the medical field, but it has a justified bad reputation. If you choose the Mumps programming language for a new project (as opposed to maintenance of an existing project where you don't get to choose the language), this is professional malpractice, and that goes double if the project is in any way safety-critical.
You have been warned.
And I heard people do use NoSQL for "important" data, and NoSQL is basically a reinvention of M as a square wheel and with no good parts of it.
I'll give my goods and bads after about 3 years.
Good: 1. Its behavior is very predictable, both in performance and for conditional behavior. 2. Error handling is not leaky, which helps with predictability. 3. Memory sharing is pretty isolated when it comes to processes / threads, much like erlang
Bads: 1. If you want to do any sort of polymorphism or code reuse, consider yourself screwed. 2. It feels like assembly, everything ends up being tacked together and tangled for code reuse 3. What you write, and what you edit, and what you depend on will be long lived; version control blame will show code still running in production from before you even finished elementary school. Refactoring is impractical. 4. Event driven designs are nearly impossible to do in this environment. 5. Local environments are not a thing. You code in the same mainframe everyone else does. Good luck.