[HN Gopher] MUMPS
       ___________________________________________________________________
        
       MUMPS
        
       Author : surprisetalk
       Score  : 44 points
       Date   : 2025-06-13 20:52 UTC (2 hours ago)
        
 (HTM) web link (en.wikipedia.org)
 (TXT) w3m dump (en.wikipedia.org)
        
       | EvanAnderson wrote:
       | Worth linking for a hotter take:
       | https://thedailywtf.com/articles/A_Case_of_the_MUMPS
        
         | BeFlatXIII wrote:
         | S Y=$C(34),X="W ""S Y=$C(34),X=""_Y X ""F %=1:1:6 W
         | $P(X,Y,%),Y,Y"" W Y,"" X X""" X X
        
           | roywiggins wrote:
           | I ran across SHA1 implemented in MUMPS once. And handwritten
           | bitwise operations, since MUMPS doesn't have those as
           | operators.
        
             | timschmidt wrote:
             | Oof. Unrelated to MUMPS, but the worst I've ever run into
             | was a reimplementation of PHP's register_globals 20 years
             | after it'd been patched out as a security nightmare,
             | because the developer enjoyed the convenience.
        
         | dang wrote:
         | _A Case of the MUMPS (2007)_ -
         | https://news.ycombinator.com/item?id=36268931 - June 2023 (109
         | comments)
        
       | kiernanmcgowan wrote:
       | Hey there to all the EPIC kids poking their head in this thread.
       | Where did you all end up post-EPIC?
        
         | vwem wrote:
         | Went to a smaller company for a short time, than ended up at
         | FAANGs.
         | 
         | Epic had some nice features and it was really cool working
         | directly with nurses and doctors. But it has some churn issues
         | and the software sucks to use, especially with Epic's
         | insistence on "all software built in house". While a good
         | marketing ploy, it results in reinventing crappier wheels.
        
       | mandevil wrote:
       | Looks like someone just got hired to work at Epic!
        
       | paxys wrote:
       | > First appeared 1966; 59 years ago
       | 
       | That's honestly impressive. Though I don't envy people who have
       | to work on this stuff.
        
       | exizt88 wrote:
       | > OPERATORS: No precedence, executed left to right, parenthesize
       | as desired. 2+3*10 yields 50.
       | 
       | How do you even come up with this?
        
         | Jtsummers wrote:
         | It's easier to parse since you can process it in-order, makes
         | for an easier single pass approach.
        
         | tbrownaw wrote:
         | Simplicity of implementation?
        
           | skissane wrote:
           | Not just simplicity-the original implementation was for a
           | very resource-constrained 1960s minicomputer, where a more
           | complex implementation would have slowed the system down even
           | more and left less memory for running the actual business
           | application
        
         | jorkingit wrote:
         | Smalltalk does the same thing!
        
         | valleyer wrote:
         | Because it's dead-simple to parse? Remember that not all
         | machines back then had hardware call-stacks.
        
           | tuveson wrote:
           | It's definitely easier to parse, but you can use shunting
           | yard to do operator precedence parsing using very little
           | extra memory and no recursion. I feel like the language is
           | just poorly designed.
        
             | skissane wrote:
             | To be charitable to its original designers, information was
             | much less easily accessible in the 1960s than today-
             | although the shunting yard algorithm had been published in
             | the research literature in 1961, practitioners working 5-6
             | years later may plausibly have been unaware of it-it wasn't
             | like nowadays where they could easily discover it in
             | Wikipedia or by asking an LLM.
        
               | tuveson wrote:
               | Yeah, that's fair enough. I'm sure a lot of weird / bad
               | language design choices can be chalked up to this
               | (COBOL...). Now that C and Pascal derived languages have
               | been around for a long time, even if you don't know about
               | how parsers work, everyone knows that certain syntax /
               | semantics are at least possible since they're the norm,
               | and I suppose that wasn't the case back then.
        
           | thomascountz wrote:
           | Would reverse Polish notation be just as easy to parse and
           | interpret?
        
             | ofalkaed wrote:
             | RPN is slightly easier to parse and interpret but more
             | difficult for most humans to parse and interpret. This is
             | the middle ground that most everyone can quickly and easily
             | adapt to writing and reading but would still be efficient
             | on most any system.
        
         | randomNumber7 wrote:
         | Tell me you would have come up with a Pratt parser yourself (or
         | even a parser generator).
        
         | Arnavion wrote:
         | PSA: POSIX shells (bash etc) do the same thing for && and ||.
         | `true || false && false; echo $?` will be 1, not 0, because it
         | evaluates `true || false -> true; true && false -> false`, not
         | `false && false -> false; true || false -> true`. Don't assume
         | like I once did that they have precedence like they have in C
         | etc :D
        
         | gnulinux wrote:
         | I implemented the same in some of my programming languages. If
         | you look into very generic mixfix operators in some languages
         | like Agda, you'll realize that operator precedence _is a mess_
         | and it feels so much better to get rid of it. Of course, it
         | makes the language unusable as a mainstream language, but it
         | makes so much more logical sense.
        
         | koakuma-chan wrote:
         | Who came up with math precedence? Why is multiplication done
         | first?
        
           | roywiggins wrote:
           | The explanation that makes most sense to me is that it's
           | mostly to avoid having to explicitly write out parentheses a
           | lot of the time. Especially for things like polynomials,
           | which are a bunch of multiplied terms added together, eg
           | 3x+2y and not (3*x)+(2*y). And in polynomials you can even
           | drop the explicit multiplication symbol, so it's much neater.
           | And once you've done this for algebra now you have to do it
           | for plain arithmetic as well to make it all match up, and
           | 3*5+2*7 gives the same answer as evaluating the polynomial at
           | 5,7
        
       | skissane wrote:
       | The core idea-a language with a built-in persistent key-value
       | store-is actually pretty cool.
       | 
       | The classic implementation is filled with horrible warts,
       | although arguably many of them were helpful in squeezing a
       | production multiuser system into the tiny resource constraints of
       | the original 1960s implementation platform (18-bit PDP-7, same
       | machine as Unix was birthed on, although Unix soon moved to the
       | 16-bit PDP-11, which was in practice more spacious)
       | 
       | Modern implementations make many of those warts optional,
       | although they still support them for backward compatibility
       | 
       | The biggest problem with the language in practice is that many
       | major code bases (e.g. VistA) are still predominantly written in
       | the legacy extremely terse coding style rather than a more modern
       | readable style. I do wonder why there isn't more effort put into
       | migrating to a more modern style, especially since with the kinds
       | of tools we have nowadays that migration could be (at least
       | partially) automated.
        
         | mamcx wrote:
         | FoxPro(dBase family) was a much better take on the idea.
         | 
         | I also dream of something modern like this (https://tablam.org)
         | but is certainly a significant undertaking. Accept partners!
        
           | skissane wrote:
           | > FoxPro(dBase family) was a much better take on the idea
           | 
           | xBase is arguably a very different idea - it is based on
           | flat-file/key-indexed databases, akin to VSAM on IBM
           | mainframes, but wrapped in a 4GL. The experience of xBase is
           | very similar to many mainframe 4GLs, what made it distinctive
           | was providing that experience on low-end platforms (it
           | started out on 8-bit CP/M systems, but it was on 16-bit DOS
           | that it really took off)
           | 
           | By contrast, MUMPS has multidimensional associative arrays as
           | a basic data type, and the difference between temporary (in-
           | memory) and persistent (on-disk) arrays is simply whether the
           | variable name is prefixed by a caret. Perl's tied arrays are
           | close, but tied arrays are a rather peripheral feature of
           | Perl (many Perl code bases never use them), but a central
           | feature of MUMPS
        
       | cmrdporcupine wrote:
       | These kind of hierarchical / network database systems are what
       | caused E.F. Codd to tear his hair out and write
       | https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
        
         | jampekka wrote:
         | Codd tore his hair out also about it becoming SQL.
        
       | telecomhacker wrote:
       | Part-time MUMPS programmer here for a health system in NYC. I
       | still love writing in it. The rates are way better than other
       | eco-systems (e.g. Python, Java, blah blah) , probably because the
       | eco-system isn't diluted with low-wage workers from India/China.
       | This is because 95%+ of Epic/Ex-Epic employees are American. I
       | would even argue it is the patriotic language of choice due to
       | that reason.
       | 
       | Expected pay of 85-120/hour, which pays way more than my full-
       | time job. It's a fun language to write in, and the adrenaline
       | rush you get when you get a triple index loop working is awesome.
       | 
       | Also random fact - according to Epic HR , the average college GPA
       | of Epic employees was 3.5, which is probably the perfect formula
       | in hiring loyal corporate servants. I always thought it was weird
       | that I had to apply with my transcripts and resume.
        
         | jampekka wrote:
         | I'm not sure I love paying it with worse health services
         | though. My city has sunk almost a billion dollars into a
         | dysfunctional Epic pile of MUMPS.
         | 
         | But I guess it's nice to see the healthcare software disgrace
         | works well at least for some.
        
           | skissane wrote:
           | > My city has sunk almost a billion dollars into a
           | dysfunctional Epic pile of MUMPS.
           | 
           | I don't know if the alternatives - e.g. Oracle Health/Cerner
           | - are really that much better - and if Epic is as bad as you
           | say, I suspect that says more about their corporate culture
           | than choice of programming language
        
             | jampekka wrote:
             | That was the story why Epic was chosen. It was made to be a
             | dilemma between Epic and Cerner, by design.
             | 
             | In reality it's not a dilemma. In other cities and
             | countries there are EHR systems from other vendors that
             | work less bad and with lower cost.
        
           | telecomhacker wrote:
           | I primarily work on clinical data, and from that side, the
           | technology stack--MUMPS included--has its quirks but
           | generally gets the job done. The real dysfunction in U.S.
           | healthcare isn't the software or the language itself, but the
           | system it's built to serve. The core issues lie in the
           | incentives around revenue cycle management and the structure
           | of the insurance industry. Blaming MUMPS is like blaming
           | COBOL for bank fees--it's the system, not just the syntax.
        
             | jampekka wrote:
             | I'm not from US. The dollars were converted from euros. Our
             | Epic/MUMPS installation is 100% tax funded single-payer
             | with no insurance company involvement.
             | 
             | But MUMPS is indeed more a symptom of a rotten industry.
             | E.g. the bidding process that led to this mess was very
             | corrupt, from all sides.
        
         | BeFlatXIII wrote:
         | Makes me curious about getting MUMPS to run locally on a Mac. I
         | had great fun with it 15 years ago.
        
           | twoodfin wrote:
           | https://hub.docker.com/r/intersystems/iris-community
           | 
           | Should be super easy.
           | 
           | There's also a native Apple Silicon tarball that I'm not sure
           | is as easy to get your hands on.
        
         | Dig1t wrote:
         | Man this is an interesting comment.
         | 
         | >probably because the eco-system isn't diluted with low-wage
         | workers from India/China.
         | 
         | Are there other technologies like MUMPS that have the same
         | characteristics?
        
         | burnt-resistor wrote:
         | That's far too low if those are current USD figures; you're
         | hurting your and others' incomes by working too cheaply in a
         | niche field. I was making $280k TC as a Rubyist at Meta or
         | $10k/week consulting _10 years ago._ That 's not anywhere near
         | as niche as Erlang/Elixir/Phoenix, OCaml, embedded Haskell, or
         | embedded Rust. Or COBOL. ;o)
        
           | telecomhacker wrote:
           | It's purely remote and super chill. Not everyone wants to
           | work on ads/compete with Indians/Chinese. I'd rather make
           | 200k helping clinicians be more efficient using ML than
           | $300k+ optimizing two tower models to increase the CTR on
           | ads.
        
         | coderjames wrote:
         | > I always thought it was weird that I had to apply with my
         | transcripts and resume.
         | 
         | I similarly thought it weird when Garmin asked me for
         | transcripts when I applied there a few years ago. It had been
         | 15 years since I'd graduated, so I was lucky I still had a
         | couple copies of my official transcripts from back then. After
         | spending the effort to find and scan them in with my 3.8 GPA,
         | didn't even get a phone screen.
        
       | roywiggins wrote:
       | Feast your eyes on Cache Server Pages. Mumps on the web.
       | 
       | https://docs.intersystems.com/latest/csp/docbook/DocBook.UI....
        
         | jampekka wrote:
         | The layout being broken on mobile is totally on-brand.
        
       | zeruch wrote:
       | I learned MUMPS years ago at UC Davis (Dick Walters, one of the
       | language maintainers, was tenured there) and I found it a really
       | interesting, but deeply weird language. Walters himself was a
       | considerate, patient dude with me, struggling to deal with at the
       | time a truly strange beast.
        
         | burnt-resistor wrote:
         | That's where I heard about it. I was a student from 2000-2009
         | when Sean Davis was around.
         | 
         | If anyone remembers, CSIF used NIS (not even NIS+) and all
         | password hashes were available to everyone on any cluster
         | machine by running `getent passwd`. John the Ripper found about
         | 90 short/dictionary-based passwords within one minute on a
         | machine of that era.
        
       | moomin wrote:
       | Obligatory: https://thedailywtf.com/articles/a_case_of_the_mumps
        
       | dang wrote:
       | Related. Others?
       | 
       |  _A Case of the MUMPS (2007)_ -
       | https://news.ycombinator.com/item?id=36268931 - June 2023 (109
       | comments)
       | 
       |  _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)
       | 
       |  _Isn 't There a Vaccine for MUMPS?_ -
       | https://news.ycombinator.com/item?id=17898927 - Sept 2018 (2
       | 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)
        
       | clabretro wrote:
       | Great hands on video with MUMPS: https://youtu.be/Ij9k7EQ5AZQ
        
       ___________________________________________________________________
       (page generated 2025-06-13 23:00 UTC)