I started coding in MUMPS 35 years ago, and have continued doing so for most of the years since.

For my first 8 years I used a version called MIIS, which was developed by Meditech. MIIS allowed 2 KB symbol space per job and 2 KB code space. Amazingly we supported libraries, hospitals and laboratories. The hardware we used were DG Eclipse and MV minicomputers; however, it also ran on DEC PDP and IBM Series/1 machines. I remember hearing that the MV systems could hold 2 MB of RAM, but it was found that the 2nd MB didn't add much performance-wise. These systems supported dozens of printers and terminals.

Since then I have mostly used Digital Standard MUMPS (DSM) and Intersystems Cache and again this has been in support of medical information systems. These systems allowed for much larger memory partitions for each job. I coded CRUD applications, reports and interfaces (both with other computers and with automated instruments). I also developed inhouse web applications, using Cache's advanced object system and SQL interface.

MUMPS/Cache runs on everything from the Raspberry Pi to mainframes. I knew one guy who developed a multi-user accounting package that ran off of a PC-AT. I've never heard of another language that could operate in multi-user mode in such constrained conditions, except for Forth. Maybe C under Coherent? The ability to run on different architectures enabled lab info systems vendor, Sunquest, to increase their revenues by selling to clients who would only accept IBM hardware, where previously Sunquest had only sold DEC boxes. I don't believe much in the code had to be changed to facilitate the transfer to mainframes. Yet another lab systems vendor, Antrim, used Micronetics Standard MUMPS (MSM) on RS/6000 boxes. I worked on interfaces to automated lab instruments for Antrim.

While my first MUMPS implementation was from Meditech, I had a different experience from the individual who reported using Magic:

. MIIS had both global and local variables
. I don't remember if variables had to be capital letters, but other versions did/do not have such a requirement
. System functions were not so obtuse
. Modern variations, such as Cache and maybe GT.M from FIS, allow communication with other languages

While the early versions of MUMPS did not support object-oriented code or graphical displays, they did support VT-220 style terminals and the displays were quite nice. This was in the early 80's. So while some companies produced products with roll and scroll, others supported formatted screens.

While MUMPS code looks odd to someone unacquainted with it, with a bit of use, it becomes obvious. This is nice because most of the code I've seen still uses single-character commands and 2 or 3-character function names. I really view this as a matter of experience: Haskell code looks like gibberish to me and I only understand a portion of Klong (which is patterned after K).

I had brief forays into COBOL and Fortran earlier in my career. And I determined I preferred MUMPS: It made lots of things easier and avoided some common problems in those other languages (such as moving too many spaces into a Fortran variable - which would both clear the variable and part of the program's code at the same time).

I really enjoy learning new languages and using them. I have coded a project using bash, awk, and Klong, which was a hoot for me. And they all have tricks which MUMPS does not have. Of course they are all just youngsters compared to this almost 50 year old language, too. And while it may not be the best language out there -- whatever that means -- it has powered libraries, credit unions, medical systems (including the Veteran's Administration which has one of the world's largest medical system), banks and stock brokers (TDAmeritrade). I hear even the European Space Agency is using it to map the heavens.

Perhaps most importantly to me, it has provided a means to feed and house my family and in my later years allowed me to be mobile, through working remotely (never even meeting my employer face to face). I imagine that it will continue to morph and serve the data processing needs of many as the years roll on.

Thanks for reading.

Steve