The MUMPS 76 Primer – anniversary edition

[flagged]

The project is intentionally about the MUMPS 76 standard and its anniversary, see https://github.com/rochus-keller/MUMPS/blob/main/Readme.md.

Agreed, I just wanted to point out that it is still around!

In case anyone is wondering why anyone should give a shit about this language, the relevance of MUMPS is that the largest market share holder of EHR systems is Epic, and their core database still runs on MUMPS.

You life, quite literally if you find yourself in a hospital, depends on MUMPS.

The second largest competitor, Cerner/Oracle Millenium, runs on MSFT SQL, and it's on life support. Last I heard, Oracle was looking to unload it.

> Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night

I don't know mumps very well, but this seems pretty straightforward if you put the primer next to it, and I am troubled by your (common!) reaction to alien technology...

> Stringly typed with literally no other types? Uh…

like this example here; SQLite made this choice too. Everyone knows about SQLite by now, right?

All types are strings when the user types them in, whether you are talking source code text, or the patient's weight in kilograms. Pretending you can have other types is something the source code of your application (or the language your application is written in) does.

This is something that makes total sense when you are thinking about things the right way (whatever that means), so when something makes you go "uh" try inverting this equation, and ask yourself, in what way (or under what circumstances) would this decision make sense?

That sort of thinking will get you the right ideas to understand everything else in the software world, and make you less avoidant about filling in the gaps in your own abilities.

> It had some neat ideas

Has. Multiuser support is still almost nonexistent in mainstream programming (and just recently starting to actually show up in SQL implementations!). And besides SQL, the most popular language with global variables you've might have heard of is perl. Understanding these ideas is still in the future.

Putting the ideas in the past, and framing them with such harsh judgement -- especially the ideas like this that you don't fully understand yet -- keeps them out of your mind, and denies you access to what these ideas can do for you.

As an example: A lot of people make a "users" table in SQL for the users of their application. Of course most SQL implementations have "users" of their own, and have a robust implementation that is already there, and yet almost nobody uses it and chooses to make their own rather than learn how to use the one SQL gives them.

Now: SQL exfiltrations are only possible because of this, and when you fully understand why that is you'll probably never make another users table again.

> and some absolute nightmare fuel.

but nightmares? Seriously? There was nothing in that example code that I am going to have nightmares about. It seems very well thought out (unlike say, Python's). It's even Y2K compliant. There is even a few ideas in there I'm going to steal for my own parser.

There is good stuff here; don't give up.