A Case of the MUMPS (2007) | Hacker News Reader

A Case of the MUMPS (2007)

thedailywtf.com

106 pointsahiknsr109 comments

For context, MUMPS is from 1966. It’s a database access language created for hardware constraints which are hard to fathom today:

”Early MUMPS memory partitions were limited to 2048 bytes so aggressive abbreviation greatly aided multi-programming on severely resource limited hardware, because more than one MUMPS job could fit into the very small memories extant in hardware at the time. The ability to provide multi-user systems was another language design feature. The word "Multi-Programming" in the acronym points to this. Even the earliest machines running MUMPS supported multiple jobs running at the same time. With the change from mini-computers to micro-computers a few years later, even a "single user PC" with a single 8-bit CPU and 16K or 64K of memory could support multiple users, who could connect to it from (non-graphical) video display terminals.”

(https://en.wikipedia.org/wiki/MUMPS)

How would you design a programming language that operates concurrently on a large shared database with just 2 kilobytes of scratch memory available for each process?

Oh, and the CPU to execute these concurrent jobs clocks at 0.5 MHz, and Unix won’t even be invented for another five years, so your implementation will of course be in machine code. You’re practically designing the operating system as part of the language.

It’s fascinating and somewhat horrifying to think that a system designed for this bygone era still survives in its own special vertical.

Horrifying for developers, but such longevity is great for the client

Yeah, there are downsides to old tech like this (hard to find developers, for one) but some of these old systems (especially the AS/400) seem to have an appliance-like operational profile that modern stacks make hard or impossible.

I know someone who built a business selling software on such systems. Business BASIC -- so basically, regular BASIC with COBOL-like data access primitives and decimal math. The machine had 64 KiB of RAM and could support 8 users at once. Even when I was growing up, a machine with 64 KiB wasn't worth really taking seriously. Those were for kids like me -- the C64 and that. But back in the 70s they ran whole businesses on one.

Many major medical systems used in hospitals are run on MUMPS. It's currently branded as Intersystems Caché.

https://www.intersystems.com/cache/

>It’s fascinating and somewhat horrifying to think that a system designed for this bygone era still survives in its own special vertical.

Why is it horrifying?

It's actually a pretty awesome product. Its used by some top EMRs like Epic and Meditech. I used to think this story was insane then I worked with EMRs. Multivalue databases have their place and are very good for people records. You will also see innersystems cache and iris used in many government and intelligence sectors.

Adopting Epic seems to mean inviting a disaster. In Helsinki doctors are resigning to avoid using the system, it's so bad. You'll easily find similar stories elsewhere, for example

https://www.healthcareittoday.com/2017/02/21/denmarks-health...

https://ehrintelligence.com/news/uk-epic-ehr-implementation-...

MUMPS (aka 'M', MUMPS loves brevity to the point of obscurity) was - without anything else coming close - the weirdest language/runtime I've ever had to work with. Fun times, though, especially when someone accidentally deleted the editor. Now, how that could happen requires some insight into how mumps works under the hood: the in system editor (which, on that particular distribution was called 'e') is a string. Just like any other string you can assign a value to it and there weren't that many safeguards in place to protect important strings.

Recovering from that particular 'oopsie' cost me a day and a bit, part of which was to write a rudimentary editor, without an editor. I think I got some apple pie out of that one :) I don't regret having seen the last of 'MUMPS' but it is very persistent and in healthcare and insurance you still come across it every now and then.

Mumps has some interesting aspects though, one of these is that it raises evaluation of expressions to a way of life, and in that sense it is closer to a functional language (but with statements, if that makes any sense) than your typical interpreted language from that era, which had strict barriers between code and data.

I actually took a University course in M by one of its maintainers, the late Dick Walters. While I never found any personal utility in the language, it was a curious 3 months of experimentation, and Walters was a great professor and fairly kind and helpful, probably because he realized how eccentric and borderline archaic M was.

I would have loved to follow such a course. Whatever I know and remember of it was learned 'the hard way' by reading code and digging into whatever problems it exhibited, not exactly a fun experience. But I have to admit: some of it was extremely clever and if you let go of the Unix file based mindset for a bit it actually was an interesting and refreshing experience. But I didn't think MUMPS was future proof enough to warrant investing more time into it and the only reason it still hangs on is for the same reason COBOL still does: large codebases that businesses rely on even if there isn't anybody there that still fully understands them.

The Finnish capital area gov bought the health system from Epic systems made with Mumps for ~500 million € around 5 years ago, despite every software professional saying they shouldn’t.

And just like predicted it’s utter dogpoo now that it’s being deployed, and has already caused a bunch of health hazards and people quitting due to its impossibly bad and confusing interface.

You can guess will it be cheap to fix it now, as it probably was delivered up to the waterfall spec, and there is that one company in the world that owns the code and can change the software.

Worst case of corruption I’ve seen, in a country where its a saying we don’t have corruption.

The same thing happened with the Epic implementation in Copenhagen (which might have been before Finland? I forget). But it also happened in Trondheim in Norway at the end of last year: everyone said it was a terrible idea, both technical and medical people, they did it anyways, and everything when straight to hell.

I knew Helseplattformen in Trondheim was an IT scandal, but holy cow, I didn't know they used MUMPS.

Its not a bad language once you get used to it and the ability of Cache to scale is past what I have seen with other database products. (I work on an EMR that also happens to use Cache and know some Epic people)

Edit; just going to link one of their docs https://learning.intersystems.com/course/view.php?id=417&sso...

Finland has some great programmers, why did they buy from Epic..

Because buying an off-the-shelf solution from an established American supplier sounds like it's going to be cheaper and better than starting from scratch. To some people at least.

It definitely sounds better if it means some money/favours will be passed under the table to you or your friends.

These B2B transactions are about buying as much protection from responsibility/liability as you can. And possibly a couple more golf friends. Nothing to do with the quality of the software...

Also in Finland we decided to buy off-the-shelf taxation software from American Gentax. I believe it has VB.net core.

Developing a new EHR from scratch that could be used in a modern healthcare system is a huge undertaking. Even a large team of great programmers would need at least several years to build something minimally acceptable.

The bit about the best developers graduating to work on Visual Basic components had me thinking of Epic. And now they are mixing in web workflows a well. :-P

As a Finn living in USA, I got recruiting email from Epic at the time. I think they may have been scouting people who speak Finnish in USA to recruit them. I just searched my email and the position was called "Finnish Integration Engineer".

I didn't even entertain the idea; I was aware of Epic's reputation and their awful software. Not to mention I might have had to move to their state for the job.

From https://en.wikipedia.org/wiki/MUMPS

Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables, so the following is perfectly legal MUMPS code:

    GREPTHIS()
           NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
           IF IF=THEN DO THEN
           QUIT:$QUIT QUIT QUIT ; (quit)
    THEN  IF IF,SET&KILL SET SET=SET+KILL QUIT

    MUMPS can be made more obfuscated by using the contracted operator syntax, as shown in this terse example derived from the example above:

    GREPTHIS()
           N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K"
           I I=T D T
           Q:$Q Q Q
    T  I I,S&K S S=S+K Q

Is that actually a grep? Which variable is the string you're grepping?

No, in this context, "grep" is more of a threat than anything.

This snippet just sets a few variables before returning "R" if the function was called in a functional context, or quitting with no value if the caller doesn't expect a value.

Since "K" is a non-truthy, but non-null value, "l1" is never added to S in the T label. "l1" is another non-null-but-false value, so S wouldn't have changed value anyway. The entire thing is just an ugly looking no-op.

It's surprising how common MUMPS is (or certainly was in the 1980s through 90s when I briefly used COSTAR). Basically if it's an old medical records database or system it could be MUMPS. Also, very weird language, it reminded me a lot of 80s-era BASIC, if accidentally altering a variable in BASIC could corrupt some medical records.

Also does anyone remember MQL ("Medical Query Language")? It was a way for doctors to write queries on the MUMPS database. As I recall it was totally imperative (unlike SQL) so basically any query started with an outer for loop over patient records. Any query even slightly complicated involved nested loops and the associated O(n^k) performance.

Edit: Found a paper describing MQL: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2578357/pdf/pro... which includes this example:

  10 FOR EACH PATIENT ; WHEN PRIMARY MD IS SMITH
  20 WHEN DATE AFTER TODAY-1 YEAR, DIVISION IS DX, CODE IS TUBERCULOSIS
  30 LIST NAME, UNIT NUMBER, DATE, STATUS

(To be fair this is far more approachable than writing the equivalent in raw MUMPS)

It looks like SAS, which is equally horrible since it inherits all the limitations of punch card input from System/360.

SAS is a great language—shame it’s proprietary. It is very well suited for data processing.

Wow, I remember reading this article when it was new. This was such a trip down memory lane. I really enjoyed The Daily WTF, but for whatever reason I stopped reading it over the years.

But reading this reminds me of my favourite article there: https://thedailywtf.com/articles/itappmonrobot

It has an odd beauty to it.

Short, memorable: https://thedailywtf.com/articles/the_brillant_paula_bean

I stopped reading it because of its formulaic storytelling. I loved the actual stories. Weird, unfortunate programming hijinx that some unfortunate new hire had to deal with. I’ve been there, or near enough, tens of times throughout the time I worked at a boutique consultancy.

The problem I have, though, is their “set it up and knock it down” style of storytelling. It gets old, fairly fast, and once you’re over it you’re just constantly hunting for the actual meat of the story. The actual development WTF.

I don’t care that Grunthilda was a seasoned developer who had recently taken a job at a mediocre teapot manufacturer, whose boss was idiosyncratic and kept shouting “the shorter the better”. I don’t care if Francisco had just started his second job within an up and coming banana republic and all of the other developers has warned him against naming variables starting with a vowel.

Just tell me what off the wall programming mistake they were making.

Now you can just rewrite it with GPT

Today's The Daily WTF is very direct, usually just one intro paragraph and then the wacky code or process. Maybe more your speed?

Ah yes, now I remember why I stopped reading it...

Used to write MUMPS at a certain company, and there were lots of "wtf" moments but this is one I'm particularly fond of. In the system, all dates are represented as an integer starting from an arbitrarily defined earliest date represented as 0, December 31, 1840 (http://www.mumps.cz/gtm/books/pg/UNIX_manual/webhelp/content...). OK, fine, whatever. But another fact about MUMPS is that associative arrays (= Python dictionaries, or Java maps) are automatically sorted. Weird language feature, and probably a questionable one, but also on its own, not the worst thing in the world.

However, these two facts put together mean that date-keyed associative arrays are always ordered from earliest to latest, and for reasons that I've forgotten, it was at least at one point inefficient to use the MUMPS facilities for reverse traversal of the associative arrays.

The solution? Defining another date format, which is `121531 - $d` where `$d` is a value in the standard MUMPS date representation. This was then used instead of or alongside the standard representation for indexing associative arrays.

Practically, this was a huge hazard for code correctness as you needed to be absolutely sure of which format the date number was in. This additionally marks Monday, September 27, 2173 as the festive occasion of date sorting doomsday, as it is the date on which the secondary format would cross over into negative values and probably start causing all kinds of subtle bugs throughout the system. Let's hope we will have moved on to better systems by then!

Say you worked at epic without saying you worked at epic.

Ha! I was going to say the article clearly referencing Epic.

I'm an emergency physician in a US healthcare system (run by the federal government) whose electronic medical record is apparently written in MUMPS.

Dealing with simultaneous crashing patients and crashing EMRs is a challenge. Daily popups notifying me of out-of-bounds index errors or [insert memory safety error] that I've given up screenshotting and sending to IT, because none of them know MUMPS either. Can't order a critical medication or view the result of a critical lab result because EHR is crashing again...

In spite of at least basic familiarity with bash, python, go, rust, nix, and having at least looked into Haskell, Common Lisp, and a few others... the few snippets of our EHR's backend MUMPS I've seen completely unintelligible to me.

My understanding is that the bus factor for vast swaths of our EMR infra is ~1.

OH MY GOD does the VA _still_ use CPRS?

The VA is replacing CPRS (built on Mumps) with an Oracle Cerner commercial EHR. This transition is very complex and is scheduled to continue through 2028.

https://digital.va.gov/ehr-modernization/news/

Nope, not the VA, just someone that borrows much of their codebase. (EDIT: but yes, I think the VA is transitioning to Cerner but still on CPRS for the time being.)

I quite liked working in M (fka MUMPS) when I had the chance to.

It's terse. Language commands can be abbreviated to one letter, and the syntax is whitespace-aware, so you can fit a lot of code on one computer screen, take it in, and review it.

If you're curious, I wrote a tutorial for it at https://learnxinyminutes.com/docs/m/

this caused me physical pain but thanks for writing it

I always liked the abbreviated commands in M and always wondered why no other programming language (that I've used anyway) has adopted it.

Sinclair BASIC does something similar

You could probably write an editor plug in that would abbreviate commands for coding and display, while still using the complete commands for the underlying source code files.

Shows you how varied career trajectories can be. Most people need a job for money and in a shitty market anyones first job can be like this, even if they have potential to be great, this can set people back. Really I advise anyone to default look for another job as soon as they get their first one. (Whether you take that job depends, but good to see what else there is once income has been secured)

Not to really disagree but one can also get into a mode where there is perpetually greener grass on the other side of the fence.

However, as I say don't really disagree. If you're pretty sure you "settled" because of lousy market conditions, at least be ready to start looking if things stabilize or start to turn back up.

Job searching is tedious at best and miserable at worst.

However, casually browsing through job openings while you already have a satisfactory job is a lot less stressful, and easy to recommend.

You also get to negotiate from a position of relative strength as your BATNA is your current job. At most it’s the opportunity cost of interviews (and maybe risk of your current job knowing your looking if that’s an issue).

Literally more green since new jobs outpaced raises. That’ll be true in the future too.

> in a shitty market anyones first job can be like this, even if they have potential to be great

That's why you need to look around, question things

I've been guilty of being interested in some needlessly complicated things, but not up to this point, and I could smell the BS from afar

Also staying in one place/one camp means career death (or grave disease ;) ) sooner or later

Some of the ideas from MUMPS (like global transparent object persistence) were useful, and with the syntax modernized and some rough edges smoothed, you can enjoy them with MUMPS spiritual successor, YottaDB. I highly recommend it to try.

I still work with Meditech Magic, which is derived from MUMPS. Meditech was founded by Neil Pappalardo, the original developer of MUMPS. A strange system for sure, but it is incredibly fast and reliable. Since the early 2000s it has run on top of Windows Server, and uses a proprietary terminal emulator and encrypted telnet for establishing connections to the system. Magic has long been eclipsed by their newer 3-tier and web platforms, though there's still lots of Magic installations still out there.

The actual core OS is wild how little of the actual Windows OS is being "used". A full release of the MAGIC OS from Meditech is only a ~30MB ISO.

MAGIC relies on the Operating System Abstraction Layer (OSAL) to run MAGIC on top of Windows. It's almost like a stub, but when you boot the Windows box up it'll boot up, auto-log-in, and dump to a full screen OSAL console waiting for you to IPL the OS with various commands (like SCSI PLEASE to list boot devices).

Networking within OSAL (and in turn MAGIC) is performed by a protocol add-on in Windows attached to the NIC -- it itself handles the rest of TCP/IP itself in usermode once IPL'd.

I'm a former caretaker on a team that had a MAGIC system for historical data -- we moved onto 6.x from there, and then I moved on from healthcare IT at that point.

M, or MUMPS is a procedural language with a built-in NoSQL database - https://news.ycombinator.com/item?id=19388048 - March 2019 (2 comments)

MUMPS - https://news.ycombinator.com/item?id=18936990 - Jan 2019 (6 comments)

Introduction to the Mumps Language (2017) [pdf] - https://news.ycombinator.com/item?id=16309237 - Feb 2018 (42 comments)

The Mumps Programming Language - https://news.ycombinator.com/item?id=13859961 - March 2017 (178 comments)

MUMPS Instance - https://news.ycombinator.com/item?id=13618649 - Feb 2017 (1 comment)

Ask HN: Encryption and Security in MUMPS - https://news.ycombinator.com/item?id=13542953 - Feb 2017 (4 comments)

50 year old NoSQL DB that is better than MongoDB - https://news.ycombinator.com/item?id=12791425 - Oct 2016 (2 comments)

MUMPS, the Archaic Health-Care Programming Language - https://news.ycombinator.com/item?id=9895311 - July 2015 (49 comments)

I am a MUMPS programmer – Ask me anything - https://news.ycombinator.com/item?id=6312391 - Sept 2013 (68 comments)

> MUMPS is a procedural language with a built-in NoSQL database.

Right. MUMPS has a key/value store where values can contain more key/value pairs. You can thus construct arbitrary trees. It's possible to hang new data items onto arbitrary places in the tree. Like JSON and XML. This is useful for medical work, which doesn't fit well into the SQL model. MUMPS eventually got transactions and ACID properties, so that multiple updates to the database interlocked properly.

If you needed that kind of data storage today, what would you use?

MUMPS appeared in 1966, predating Edgar Codd's 1970 paper that would later give rise to relational databases. Additions to SQL introduced by the 1992 ANSI standard have become essential to its modern form.

So, although NoSQL is a familiar framing, pre-SQL is a more appropriate designation for MUMPS, since NoSQL was a response to SQL.

The tree data structure used by MUMPS is specifically a B-tree. This is a standard data structure and doesn't on its own give MUMPS much to brag about over other DBMSs which offer B-trees. MySQL offers B-trees as an indexing option, for instance.

Can you directly store data into a MySQL B-tree or is it only available for indexes?

Said MUMPS programmer from the last link here.

I kept working with MUMPS, although it became much more Caché ObjectScript over the years, until this March.

I’ve moved on to doing other things now, but I can see myself absolutely going back to it. But not until I’m much older.

It’s cozy, it’s comfortable and it does so many complicated things just more easily than so many other programming environments. The only thing I won’t miss is the complete lack of strict typing, a charge that can be laid on many other programming languages too.

I had the exact same experience.

The company in question is Epic Systems, maker of very popular medical records software.

The tell was "The lucky one got to program Visual Basic."

You can tell the author wasn't one of the lucky ones because MUMPS is a joy to work with compared to VB6.

I was going to comment “He must have worked for Epic”

Please tell us more!

My country's medical system is made by Epic, should I be scared?

The newly released, expensive, hated and bug-ridden system here in Norway ("helseplattformen") is by Epic, written in MUMPS/caché.

So yeah, be worried.

Yes.

Medical software dev in the US is a dumping ground for the under-qualified or people looking to coast the balance of their career.

Nah, you'll be fine. Most hate for Epic stems from 3 places: users who don't want to learn new systems, the growing pains of adapting Epic to new regulatory systems, and the general fact that an EMR let's regulators and administrators demand too much from their clinicians that couldn't be done with paper charts.

This is Epic's common strategy of blaming all criticism on "resistance to change". The thing is, their software is simply bad, and its implementation in the Nordics has been a disaster.

At the end of the day, it's complex software for doing complex tasks. Even with 0 bugs, and a "perfect UI", people would by annoyed to use it simply because the tasks that need to be done are not what they signed up for when entering healthcare. If your job made you use a eye poking machine, you'd be upset even if it was the least painful eye poking machine on the market.

The only answer is automation, and in a safety critical role like healthcare, automation has to be done with great care.

That's of course true in the abstract and general, but I'm not talking about that. A lot of the criticism in Denmark has been quite quantifiable: things like increased number of clicks to perform similar tasks, and instances of losing work and being forced to start over if you, say, picked the wrong option early in a process, increased number of steps for no benefit. And also the presence of many steps and decisions that relate to billing, which of course should not need to be made here, since no bills are ever written. A bunch of things that add up to more time spent on things that the old systems made simple.

But from Epic and the higher-ups (who have to defend their expensive acquisition), it's always the same reply even to the most concrete of criticism: you just don't like change! At some point it really moved beyond just a bad excuse and became victim blaming.

(Please know that the context here - and I think in our neighbouring countries as well - is not that there was no automation, rather there were a set of mostly functional solutions in each region that were replaced by a single top-down mandated country-wide system. There was a book published recently about the process that led to the implementation of Epic's system from which I did not get the impression that this was based on merit as much politics.)

Horsefeathers. It is an objectively bad interface.

My interactions with it as a patient have been quite good. Both my previous provider and current provider use it. All the doctors are trained on it, as well as all the staff. It makes all sorts of things quite simple, for example tranferring all my records from my previous provider to my current one was one click by my doctor. later, we could review my medical imagery in the office as needed.

From what I understand, getting to that point required a huge amount of effort on the provider's part (many thousands of hours of contractors configuring systems deep in the bowels of hospitals or data centers). But that's not surprising: anything regarding health and IT in the US eventually grows to consume our entire economy.

Same here. The hospital that my current doctors work for is on an Epic system. From the patient POV, it's quite good. Very easy to figure out where to find stuff. I've seen far, far worse UIs.

I’m not sure what it is about medical systems, but the next biggest player in this space in the US I believe is Cerner, and it’s largely written in a different oddball language. I used to work at a hospital system as sort of a general purpose developer. Had things gone a bit differently, I very well could still be there as a CCL (Cerner Command Language) guy. It’s a strange hybrid of declarative SQL-like syntax and half-baked procedural syntax.

Cut my teeth writing CCL for several years at Cerner. It has its rough points, but I learned a lot of valuable SQL optimization experience.

Looking back I can see why post-processing SQL query results using a procedural section at least gives you an escape hatch to do business reports or other iterative tasks.

I don't miss it, but I can see why CCL was designed and written at the time.

Most of why I disliked working with CCL as a client developer was because it was a pretty poor developer experience. The tooling was cumbersome, the feedback loop was long, no easy way to do source control (I think they were working on improving that aspect), and of course the limited user base comes with its difficulties. Not that any of this is particularly surprising for a homegrown programming environment.

Hey, what if they wanted to use another database than Oracle and not have to rewrite all the SQL.

Maybe my mind has already gone insane but I’m reading the part where the company is using the language “cleverly” and all I’m seeing is software engineering practices being applied to a language to make it scale across large projects. Sure, you can be upset that the language sucks or whatever, but given that you have a bunch of legacy code in a language that doesn’t have modern affordances, these all seem very reasonable and in some cases almost admirable. I’ve been in codebase with similarly poor languages (BASIC, C, assembly) and doing things like imposing “namespaces” or refactoring code into “modules” within the confines of what your tools let you do would have been very helpful.

It sounds a lot like a FoxPro codebase I worked with. Mumps predates FoxPro by 15-20 years but some constraints applied to FoxPro that are silly now, especially 8 character DOS filenames. Both languages let you build a string that you then use as a function name and have a form of "eval". In both cases, namespaces are absent and made up for by code letters and lookup tables. In FoxPro 2.x, tables were named by their filenames. Code was shared between projects by using a 2 letter code to different the parts that were project specific. It was WTF-inducing for me at the time, coming from C++ and Pascal, but it made sense at the time. Those applications were quite fast on very limited hardware, probably 286s when the project was started.

Yet another fascinating technology from the sixties still in use today; at least the database part of it came back into fashion with NoSql; the language, on the other hand, does not exactly promote readability.

A couple of jobs ago, I was working somewhere where the big niche app they used was based on an Intersystems Cache DB. Cache is literally actual commercialized MUMPS. It had a SQL translation layer, but it was still...very weird.

I remember Intersystems Cache ads. I dreamt about how nice it would be to use as I grappled with hand crafted (remember to escape untrusted inputs!!) SQL statements in the “Lower Level Business” layer of a ASP.NET1.0 app. Sounds like it wasn’t such a silver bullet?

And there's new development done on it, in MUMPS in fact, because to fully utilize it you still need to use MUMPS.

It shows up in financial companies a bit.

If you consider funneling a non-negligible fraction of US medical costs into paying for Intersystems Cache licenses fascinating, then yes!

Those fuckers are well aware of their captive markets and extract rent like no other. The licensing costs on such an outdated piece of technology are obscene.

> extract rent like no other .. The licensing costs on such an outdated piece of technology are obscene.

They're in "good" company. Do you think its less obscene to pay the horrendous license costs to companies like Oracle or SAP?

Anyway, I'm talking about the technology, which btw. has established open source alternatives. I once had an argument with the main person in charge of hospital IT, and he made it clear that he didn't want to risk his good sleep by using technology from non-mainstream suppliers, no matter what the cost. As long as we allow such people to value their personal sleep quality over the cost to the health care system, we need not complain about the consequences.

Can you point out a few of these open source alternatives? Asking for a friend...

The most obvious alternative is https://sourceforge.net/projects/fis-gtm/, but there are a few others, depending on the size of the application at hand. https://yottadb.com/ is another big one which started on GT.M a few years ago, or http://minimdb.com/. See also https://www.mumps.dev/implementations.cfm.

If you don't depend on the MUMPS/ANSI-M language or don't have to be backwards compatible, a lot more alternatives with similar features are available, e.g. https://github.com/facebook/rocksdb run behind e.g. Node.js.

I knew of a financial system running on a DEC VAX some years ago that used MUMPS. I also know a programmer who had been employed at a local telemarketing company in the 1990's. That company used MUMPS.

He had said that they had their star-programmer there who could dash out complicated MUMPS data queries in very short order. My friend said he had some fun programming in it, but he left the telemarketing company to move on to more conventional programming languages.

I worked on the MUMPS Standard when I taught in the Medical Informatics Committee at UC San Francisco. When I first encountered the language, I was appalled. For example, in pre-standard MUMPS, lines with no trailing blanks and lines with one trailing blank had a different interpretation. For those interested, https://nvlpubs.nist.gov/nistpubs/Legacy/hb/nbshandbook118.p.... At one of the standardization meetings, I embarrassed myself by called MUMPS a "viral disease" because of the pathology of the programming language as defined to an audience of people who saw it as a practical tool they used every day. The standard helped stabilize the language. I acquired an appreciation for the incredible skill application programmers can adapt a general purpose extensible language to do their bidding.

MUMPS: A lousy language with a brilliant data structure

If you think Python's significant whitespace is bad, MUMPS is far worse. Seriously, go look up how to write an indefinite MUMPS loop.

You can still use it with a more modern syntax with GT.M and YottaDB databases, both open source and commercially supported.

I'll check it out, thanks!

A couple of things that have changed (allegedly) at the company described in this post since the time it was written:

* Most of the non-M/MUMPS code is now written in C# with a TypeScript/JavaScript web front-end. The M stuff is all database stuff and VB is pretty much gone.

* The toolchains used to manage M code and work around all the complex idiosyncrasies of the language are vastly improved and abstract away a lot of the pain of working in it (that isn't directly the result of the language itself, of course).

* The cleverness has gone off the charts, and so has the insanity. (The company tried to force all developers to work in-office during COVID until the county told them to stop it.)

Or so I've been told.

Some years ago, I co-worker's son got two offers for summer jobs: one in New York for a financial company, one in Minnesota for a company making health-systems software. The latter used MUMPS. I advised her that the son should take the New York job.

Are you sure it was Minnesota? More likely Epic in Wisconsin. They use a modernized edition of Mumps as the platform for their EHR software.

https://www.intersystems.com/news/intersystems-iris-data-pla...

Epic does have a small office in Rochester to put people close to Mayo Clinic.

Nope, you're correct. Thank you for the reminder.

This hits home as I am a case of "Bryan". 7 years of MUMPS,PSL experience as it was the first software developer job that I was offered. Always knew that I will need find a way to get out of it ...

HL7 starts to make more sense to me now.

Now I know where all the caret usage comes from!

HL7 (up to V2) was designed after EDIFACT; similarities with ANSI M (if at all) are coincidence.

FHIR JSON-LD: https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperabili...

https://github.com/topics/fhir

Actually I don't mind if I can land a 10-year job without much BS. Give me the job if it is...

So here's the question: Was Dick Pick, the creator of Pick BASIC, vaccinated with MUMPS? Pick BASIC was sort of like a version of MUMPS for people who could not afford to go to the hospital, easier to swallow, but with similar side-effects impairing cognition. One severe case of cognitive decline from Pick BASIC became visionary, yielding Advanced Revelation.

Larry Wall must've been a MUMPS fan (at least when he was designing Perl syntax)

MUMPS and Perl were both influenced by BASIC.

Programming is Hard, Let's Go Scripting... https://www.perl.com/pub/2007/12/06/soto-11.html/

> BASIC

> Now, however it was initially intended, I think BASIC turned out to be one of the first major scripting languages, especially the extended version that DEC put onto its minicomputers called BASIC/PLUS, which happily included recursive functions with arguments. I started out as a BASIC programmer. Some people would say that I’m permanently damaged. Some people are undoubtedly right.

> But I’m not going to apologize for that. All language designers have their occasional idiosyncracies. I’m just better at it than most. :-)

Reply on news.ycombinator.com