[HN Gopher] A Case of the MUMPS (2007)
___________________________________________________________________
A Case of the MUMPS (2007)
Author : ahiknsr
Score : 88 points
Date : 2023-06-10 09:11 UTC (13 hours ago)
(HTM) web link (thedailywtf.com)
(TXT) w3m dump (thedailywtf.com)
| BeFlatXIII wrote:
| Larry Wall must've been a MUMPS fan (at least when he was
| designing Perl syntax)
| shagie wrote:
| 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. :-)
| jim_lawless wrote:
| 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.
| quercusa wrote:
| HL7 starts to make more sense to me now.
| cmiles74 wrote:
| Now I know where all the caret usage comes from!
| Rochus wrote:
| HL7 (up to V2) was designed after EDIFACT; similarities with
| ANSI M (if at all) are coincidence.
| rwmj wrote:
| 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)
| xattt wrote:
| It looks like SAS, which is equally horrible since it inherits
| all the limitations of punch card input from System/360.
| SuperNinKenDo wrote:
| 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
| Noumenon72 wrote:
| Is that actually a grep? Which variable is the string you're
| grepping?
| itsTelax wrote:
| 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
| ...
| jacquesm wrote:
| 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.
| [deleted]
| dang wrote:
| Related:
|
| _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)
| Animats wrote:
| > 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?
| atemerev wrote:
| 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.
| tsurba wrote:
| The Finnish capital area gov bought the health system from Epic
| systems made with Mumps for ~500 million EUR 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.
| cmiles74 wrote:
| 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
| gedy wrote:
| Finland has some great programmers, why did they buy from
| Epic..
| kakoni wrote:
| Also in Finland we decided to buy off-the-shelf taxation
| software from American Gentax. I believe it has VB.net core.
| rvense wrote:
| 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.
| AshamedCaptain wrote:
| 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...
| Nextgrid wrote:
| It definitely sounds better if it means some money/favours
| will be passed under the table to you or your friends.
| arnsholt wrote:
| 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.
| vintermann wrote:
| I knew Helseplattformen in Trondheim was an IT scandal, but
| holy cow, I didn't know they used MUMPS.
| quickthrower2 wrote:
| 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)
| raverbashing wrote:
| > 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
| ghaff wrote:
| 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.
| piaste wrote:
| 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.
| koolba wrote:
| 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).
| pavlov wrote:
| 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.
| bitwize wrote:
| 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.
| golergka wrote:
| Horrifying for developers, but such longevity is great for the
| client
| fiddlerwoaroof wrote:
| 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.
| lucas_membrane wrote:
| 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.
| z3ugma wrote:
| 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/
| spiritplumber wrote:
| this caused me physical pain but thanks for writing it
| rpbiwer2 wrote:
| I always liked the abbreviated commands in M and always
| wondered why no other programming language (that I've used
| anyway) has adopted it.
| [deleted]
| frr149 wrote:
| MUMPS: A lousy language with a brilliant data structure
| BeFlatXIII wrote:
| If you think Python's significant whitespace is bad, MUMPS is
| far worse. Seriously, go look up how to write an indefinite
| MUMPS loop.
| atemerev wrote:
| You can still use it with a more modern syntax with GT.M and
| YottaDB databases, both open source and commercially supported.
| frr149 wrote:
| I'll check it out, thanks!
| lanman95 wrote:
| 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.
| markus_zhang wrote:
| Actually I don't mind if I can land a 10-year job without much
| BS. Give me the job if it is...
| cafard wrote:
| 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.
| nradov wrote:
| 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...
| goda90 wrote:
| Epic does have a small office in Rochester to put people
| close to Mayo Clinic.
| cafard wrote:
| Nope, you're correct. Thank you for the reminder.
| [deleted]
| hwc wrote:
| I had the exact same experience.
|
| The company in question is Epic Systems, maker of very popular
| medical records software.
| fredsmith219 wrote:
| I was going to comment "He must have worked for Epic"
| andrelaszlo wrote:
| Please tell us more!
| LoganDark wrote:
| My country's medical system is made by Epic, should I be
| scared?
| matsemann wrote:
| The newly released, expensive, hated and bug-ridden system
| here in Norway ("helseplattformen") is by Epic, written in
| MUMPS/cache.
|
| So yeah, be worried.
| dekhn wrote:
| 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.
| Turing_Machine wrote:
| 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.
| megiddo wrote:
| 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.
| goda90 wrote:
| 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.
| rvense wrote:
| 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.
| goda90 wrote:
| 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.
| [deleted]
| rvense wrote:
| 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.)
| bandyaboot wrote:
| 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.
| NortySpock wrote:
| 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.
| bandyaboot wrote:
| 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.
| BeFlatXIII wrote:
| The tell was "The lucky one got to program Visual Basic."
| rpbiwer2 wrote:
| You can tell the author wasn't one of the lucky ones because
| MUMPS is a joy to work with compared to VB6.
| Rochus wrote:
| 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.
| TylerE wrote:
| 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.
| quickthrower2 wrote:
| 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?
| p_l wrote:
| 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.
| fivre wrote:
| 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.
| Rochus wrote:
| > _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.
| surgical_fire wrote:
| 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.
| B1FF_PSUVM wrote:
| Short, memorable:
| https://thedailywtf.com/articles/the_brillant_paula_bean
| hug wrote:
| 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.
| hyperrail wrote:
| Today's The Daily WTF is very direct, usually just one intro
| paragraph and then the wacky code or process. Maybe more your
| speed?
| golergka wrote:
| Now you can just rewrite it with GPT
| lgessler wrote:
| 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/conten
| t...). 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!
| chewbacha wrote:
| Say you worked at epic without saying you worked at epic.
___________________________________________________________________
(page generated 2023-06-10 23:01 UTC)