Live data from Hacker News

Introduction to the Mumps Language (2017) [pdf]

cs.uni.edu

11–20 of 46 posts

Re: Introduction to the Mumps Language (2017) [pdf]

#12
Epic Systems (the biggest vendor of EMRs) is one of the primary users of Mumps/Caché. In the early days of the company, technical support was allowed to write in customizations for clients as long as they could fit in a single line of code. This was possible given that one 'feature' of the language is that all the reserved words have a one letter alias. So if you were one of the unlucky ones assigned to support these old customers, you'd run across stuff that looked like "s a w; a f 10; a f s w ^a;".

Re: Introduction to the Mumps Language (2017) [pdf]

#13
A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its invention:

> 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

Re: Introduction to the Mumps Language (2017) [pdf]

#15

A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its invention: > 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 com…

Also mentioned in the linked tutorial: Memory on early mini-computers was limited, sometimes only a few thousand characters. Mumps programs were loaded into memory as source code rather than as compiled binary. This was done because it was determined that compiled Mumps programs would be far larger than the corresponding source code versions, especially if the source code employed size reducing abbreviations.

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?

Re: Introduction to the Mumps Language (2017) [pdf]

#17
One company have a object-oriented database programmed under Mumps that is so backwards compatible to the point it can interface to RS232 dumb terminals and run utilites and code from the 70's. Used very much by governments and hospitals, it's one of the most insecure platforms I've ever worked.

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 D

Re: Introduction to the Mumps Language (2017) [pdf]

#18

Since this is presented without context, and there's a significant chance people will get the wrong idea, I'm going to say this directly: 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 professio…

I'm certainly glad that I didn't have to touch any M in ages and ages, but there's a good chance that your medical records, your financial records, and possibly your telecom billing is stored with a good dose of MUMPS.

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.

Re: Introduction to the Mumps Language (2017) [pdf]

#19
Of the places I've encountered Mumps/Pick/Cache, there has always been that one gatekeeper guy - only he knew the arcane abbreviations and structure in his head, everyone else had to bow and scrape to get things done.

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.

Post reply on HN