Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The MUMPS 76 Primer – anniversary edition

github.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: The MUMPS 76 Primer – anniversary edition

#31

Post by quink »

cduzz wrote: post #17
quink wrote: post #3

I did most of Advent of Code last year code golfing in MUMPS (running on Caché), with the additional challenge on up to and including day 7 doing without literals - that's to say no numbers and no strings. It was good fun - https://github.com/dominique-m-aoc/aoc-2025/blob/main/day03p... for day three part 1 for example. Or day 7 part 2 where the alphanumeric chars spell a story with only two nonsense words, with almo…

How do you think your code would do in GT.M or Yottadb? I understand both are open source (vs Cache).

Not having literal strings in the source code, I do need to get a capital “R” somewhere and the name of the system being “IRIS” in system variable $ZV makes that easy and terse. Apart from that one trick I think it’ll be more or less just fine.

Re: The MUMPS 76 Primer – anniversary edition

#32

Post by surgical_fire »

iloveoof wrote: post #16
ilcavero wrote: post #6

obligatory reference: https://thedailywtf.com/articles/a_case_of_the_mumps

This article is terrible and I hate that people always bring it up whenever MUMPS is mentioned here. MUMPS is easy to read, understand and maintain when written well. These examples (and the Wikipedia ones) are from code written when hospitals needed to run their whole EMR with extreme storage constraints, so more terse code was necessary to fit more on the disk. Of course they aren’t readable by modern standards.

Dude, chill.

That article is humor, not an essay on the merits of MUMPS.

It was entertaining to read for me back in the day, especially as my first programming job was on a COBOL system from the 80s. That in the mid 2000s.

Re: The MUMPS 76 Primer – anniversary edition

#33

Post by rybosome »

kstrauser wrote: post #12

Built-in hierarchical DB? Neat! DB access using same syntax as local variables? Neat! Datetime epoch in 1841? Ok, sure. Stringly typed with literally no other types? Uh… Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night It had some neat ideas, some alright ideas that were reasonable in the context it was created for, and some absolute nightmare fuel.

Quite agree.

Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it.

But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs.

The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.

In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.

Re: The MUMPS 76 Primer – anniversary edition

#34

Post by giardini »

fortuitous-frog wrote: post #11

For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.

Bad news! My medical co.uses EPIC! Scheissurger!

Re: The MUMPS 76 Primer – anniversary edition

#35

Post by theamk »

iloveoof wrote: post #15

MUMPS’ bad reputation is totally unearned. Most examples online (the wiki page, the awful Case of the MUMPS article) are examples of MUMPS code from the 60s-70s when storage was a premium and enterprise-size programs had to fit in a handful of megabytes, so there was no room for readability. MUMPS code is more readable than most languages, it’s very simple and procedural. And the ability to interact directly with dur…

Interacting with durable data storage is actually pretty common.

Perl is modern (-ish? Definitely modern compared to MUMPS) and had "tie" for database access forever [0]

Python's dbm interface also looks like a regular dict [1]. I am sure there are many others, I know we had one "magic dict" in one of my work projects.

It's just that transparent access has some limitations, like lack of transactions, unexpected latency, lack of strong types, inability to only change a single value.

[0] https://perldoc.perl.org/DB_File#A-Simple-Example

[1] https://docs.python.org/3/library/dbm.html

Re: The MUMPS 76 Primer – anniversary edition

#36

Post by fortuitous-frog »

Rochus wrote: post #21
fortuitous-frog wrote: post #11

For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.

Do they really use MUMPS? Not something like ObjectScript?

I can’t speak for other companies, but I worked at Epic for a few years (left last year), and indeed MUMPS is still their bread and butter. In fact, I had not even heard about ObjectScript until reading this thread.

A few years ago, they _did_ develop a TypeScript wrapper framework (which was transpiled down into MUMPS). They heavily encouraged newer application code to use this, but it never caught on, was quietly abandoned after a bit.

Internally, MUMPS was often criticized or laughed at, but I doubt it’s going anywhere anytime soon.

Re: The MUMPS 76 Primer – anniversary edition

#37

Post by Rochus »

fortuitous-frog wrote: post #36
Rochus wrote: post #21

Earlier quoted context omitted.

Do they really use MUMPS? Not something like ObjectScript?

I can’t speak for other companies, but I worked at Epic for a few years (left last year), and indeed MUMPS is still their bread and butter. In fact, I had not even heard about ObjectScript until reading this thread. A few years ago, they _did_ develop a TypeScript wrapper framework (which was transpiled down into MUMPS). They heavily encouraged newer application code to use this, but it never caught on, was quietly a…

Thanks for this interesting insight. Since they are apparently using Intersystems backends, I thought that ObjectScript might be a consequent choice; from my perspective it is rather comparable to JavaScript, so the TypeScript idea might have been stronger, but on the other hand might cause issues with (dynamically typed) globals.

Re: The MUMPS 76 Primer – anniversary edition

#38

Post by Rochus »

rybosome wrote: post #33
kstrauser wrote: post #12

Built-in hierarchical DB? Neat! DB access using same syntax as local variables? Neat! Datetime epoch in 1841? Ok, sure. Stringly typed with literally no other types? Uh… Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night It had some neat ideas, some alright ideas that were reasonable in the context it was created for, and some absolute nightmare fuel.

Quite agree. Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it. But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a n…

My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.

Re: The MUMPS 76 Primer – anniversary edition

#39

Post by dmd »

fortuitous-frog wrote: post #11

For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.

I interviewed at Epic in 2011. Got through a couple rounds - enough to see how weird and culty the place was.

I was alone in a room with one of my interviewers, who seemed pretty sharp. I asked him "do you like working here?"

He looked at me, glanced at the closed door, leaned forward and said in a low voice "nobody likes working here. If you have another option, take it."

I thanked him and left and I'm very glad I did.

Re: The MUMPS 76 Primer – anniversary edition

#40

Post by Rochus »

aduty wrote: post #29
iloveoof wrote: post #15

MUMPS’ bad reputation is totally unearned. Most examples online (the wiki page, the awful Case of the MUMPS article) are examples of MUMPS code from the 60s-70s when storage was a premium and enterprise-size programs had to fit in a handful of megabytes, so there was no room for readability. MUMPS code is more readable than most languages, it’s very simple and procedural. And the ability to interact directly with dur…

You would love OpenEdge ABL.

ABL is structurally much closer to Oracle PL/SQL than to MUMPS.
Post reply on HN