A friend of mine wrote in MUMPS, banking terminal applications. greenscreens, that kind of stuff. He hated it, but he told me then it was a job for life, he got paid well (not many people with those skills) and didn't really have a lot in the way of stress....
I used to do a lot of work in dBase & Clipper and because of that I got projects in other 'language integrated databases'(?) like DataEase, MUMPS, Cache as well as Access, Foxpro and Informix. Besides Access (I guess?) these are mostly jobs for life without stress. I still get requests and it has been 15-20 years since I touched most of those.
Not sure, but many. These are usually not very well advertised in my experience as the people who still can do this are known and/or advertise themselves to wanting to do that work.
The problem with this retirement plan isn't that it's not viable (it is), it's that you're guaranteed to be working exclusively with mismanaged and incompetent organisations and people. That gets depressing fast.
COBOL is much easier. You can easily clear $125/hr or more if you know anything at all about old school non-IBM mainframes.
Most COBOL is cut and paste. One guy I know basically reads books and updates some report, where update means enter the next month and year combination into some code, entering a change request, and go to a change meeting.
He's basically working for 3 years until his wife can retire, then building a lake house.
My comment was aimed more at tsomctl and moomin than at you, to be honest. Say "MUMPS" and people will fall over themselves to cite The Daily WTF, as if it were all there was to be said on the matter.
I, too, read the Daily WTF when that article first came out (in middle school! Time flies.) Although, to be honest, it was a lot funnier then than it is now.
I know at least one of the two top major EHR systems uses MUMPS (Epic Software) at its core. If your a member of Kaiser Permanente, or hundreds and hundreds of other hospitals/medical systems, you rely on it for your medical records..
You write that as if it's a bad thing? Epic's EHR appears to work pretty well and they haven't had many failed implementations. And InterSystem's Caché has evolved way beyond the historical MUMPS.
It was about 3 years too long. Yes, that math is correct.
As far as I recall, MUMPS is essentially the dedicated coding language for a b-tree based database, and the only reason to ever use it for anything is for processing huge numbers of transactions through your NoSQL database every second, forever. I guess you also might want it if none of your employees knew how to correctly normalize a relational database.
Other than the nightmarish accumulation of technical debt continually rolled over since 1979, and the ungodly high turnover of people jumping ship after realizing MUMPS was a golden ball-and-chain, it was a pretty nice place to work. But management had a culture that it needed to force down everyone's throats, and the tech stack was a real resume killer. I still get contacted by recruiters desperate for MUMPS developers, and they make me feel like someone trapped inside a house besieged by zombies. I get really quiet, and hope they don't break any windows.
It only works because they throw a huge amount of money at it, and no one has any incentive to cheap out on medical management software.
EPIC management's (at every level) embrace of M and all things old as holy and glorious was what turned me off of it most. I could somewhat understand the need to keep working with cold in an old, bad language because it was still printing money (most anything related to healthcare does). I could not understand that consideration any possibility of modernizing the codebase was completely off the table--there were no R&D teams looking at new developments in database design as possible improvements, even though the tech most in fashion at the time (NoSQL) had striking similarities to M's own database structure. All effort was spent towards squeezing every last ounce of blood from ossified technology. This persisted well outside MUMPS itself: I was in the server management division, which was a champion of AIX and HP/UX (and in the weirder corners, VMS) over Linux. When I left there were a few people warming to the idea that RedHat might be enterprise-y enough to serve as a base for running M databases, but general sentiment was that most customers would continue to use old school nixes well into the future. Much of our time was spent painstakingly guiding rural hospital sysadmins through manual configuration of every sysctl and OS parameter needed to make Cache happy. Configuration management would have reduced this to about 3 minutes of tossing a Chef/Puppet/Salt/whatever config at a server, but was considered anathema because it was necessary to have that special human touch involved in spinning up a nix environment--surely no automated system could understand or be trusted with the intricacies of setting ulimits to values obtained via a function utilizing, at most, three inputs and grade school arithmetic.
Since I was more in their systems department I had limited opportunity to observe their archaic superstitions about code structure, but the short introduction course to M they provided confirmed that most current and new employees were willing to accept that certain control flow tools or function structures were dangerous because they were necessarily slower than something that made sense in hand assembly programming, since there had obviously been no developments in compiler optimization since M was designed (in the good old days, before C existed).
There were no archaic superstitions about code structure. Those had to be removed, because the code had long ago grown large enough to push up against size limitations. You couldn't put comments in the code. You had to use the abbreviated syntax. If you tried to make anything human-readable, it wouldn't fit.
You weren't even allowed to touch the infrastructural M code. Mostly, you worked on superficial or peripheral M code, or on the GUI in VB6. I heard rumors of a GUI modernization team, but never saw any direct evidence of it.
It was a result of the iron grip of the top management. They didn't want to yield control of the company to the people actually running it. You were expected to use your expertise to do what you were told to do, in the best way you could, while still remaining completely within your lane.
After the 6 months of training, I gave it a year to read the character of the company, and then another 6 months to soak some potentially major family health care costs with that sweet insurance plan, then spent 4 months job hunting. It was the best employer-offered health insurance plan I ever had.
But make no mistake. Companies like Epic are why health care costs in the US are huge and growing. Epic never refactors anything that still works well enough to hold together with some expensive human labor. It is a technology company that runs on well-trained people instead of well-designed code and processes.
When did you work there?? I find it surprising you never saw anyone writing C# or TypeScript if it was any time recent. These days there's quite a bit of web-based UI replacing the VB6, though you might not notice if you don't look carefully enough.
If it was any more than a year ago, there were parts of the company that had barely started and web migration due to dependencies. Epic is still slow playing this to make sure they don't have some of the issues they had with the early 2015 releases
The size limits were for object code, not source code. Comments and short command names have no impact on object code size. Ages ago, there was a 32KB object size limit. Now you can use up to about 8MB, which is large enough for pretty much all non-machine generated code. You can, of course, just use multiple routines to avoid the limit.
Some functional areas use Hadoop and SQL now. New server development can be done in VisualStudio using Typescript (which gets converted to M).
There are automated tools to set and verify OS parameters.
Most new installs are Linux now. No one uses VMS today. HP-UX and Solaris will be out of use in a couple years. InterSystems licensing is why people continue to use AIX (you have to buy new licenses to switch from AIX to Linux).
There is a company called MediTech in Massachusetts that uses a derivative language of MUMPS called Magic. I know several programmers that have worked there. There are thousands of engineers writing in this language as we speak.
From what I can remember:
-Only global variables
-Variables must only be capital letters, maximum length 6. If you run out of variables, you must cleverly use them in a routine and set them back to what they are. This means you can't use a name like myVar - you use AAAFD, ZBVCXZ, etc.
-System functions are usually things like ., >, ', ], so code looks like .'AAAF]{\;:..
-Meditech writes all of their own languages, databases, operating systems, tools, etc. You can only write in a non-Meditech language if you get approval from a multi-tiered architectural design board, which barely ever happens
-The founder hated C with undying passion. No one is ever allowed to use C
-All programming hires go through a 6 to 12 month training process to learn the tools, languages, and systems. As they almost exclusively hire non-CS majors, such as math and physics majors, they don't typically have a programming background and don't realize how bizarre the MediTech stack is
Because MediTech engineers get experience in a proprietary suite of technologies that is only used there, it is extremely difficult for them to get new jobs at the same pay grade and experience level. 5 years at MediTech is worth 0 years anywhere else. However, I have hired a few of these people, and while they knew nothing about say Python, JS, Linux, etc. when hired, their deep understanding of how computers work made them very skilled once they picked up the modern technologies. Not many engineers program for years in low-level nightmare languages before touching JavaScript or Python, most start high-level and go lower. The foundation provided by working in a language like Magic makes them know computers at a deeper level than most.
I interviewed at MediTech while I was in college. During the interview I pointed out the issue of how working on proprietary technologies would have an impact on my career. This along with the fact that the compensation they were offering was significantly less than what I was offered as an intern at Goldman Sachs and another company no one would know.
I swear it was something insane like 36k a year in 2005. compared to 55k for GS . I asked them if it came with something to offset that like a pension or housing and they looked at me like I was crazy. I asked them to explain what they had to offer me and they made some stuff up about it being a great job with advancement potential. I think the word loyalty may have come up.
I didn't get an offer not that I would have said yes.
The lobby was nice as I recall. Lot's of open space, granite, and flowing water. Maybe that makes it worthwhile? Oh and you have to wear dress clothes. On 36k a year.
A co-worker's son had a couple of internship options one summer: one somewhere in the health world using Mumps--actually, I think it might have been VB plus Mumps--the other at a big finance outfit. I strongly suggested the latter. Whether or not my suggestion had any effect, he took the job at the finance place.
as a long-suffering user of Meditech, I would say you dodged a bullet...it still looks like you are using MS-DOS. Shoehorned into Citrix to get it to run on modern machines...
Is 36k that insane? That's the average starting salary of French engineers and some PhD-level researchers from relatively well-ranked universities. 1/3 of which are compulsory taxes (not including income tax), so in the end it's about 25k of net disposable income per year.
Healthcare is fairly expensive in the us and rent is fairly high in the Boston area. It's not the same time period but in 2014 I was paying 1800 a month for a 1 bedroom to be within a 15 minute walk of the second to last station on the light rail system, and it wasn't overly expensive.
It is insane. I started at the bottom of recession 2009 at a university for 46k.
I'm sure it depends on geography and living cost but 36k is very low imo for a private company.
Public companies such as public university, government, and such still pay a bit above that on top of good compensations (healthcare, vacations, etc...).
This is USA of course.
France in general could be different in term of tax, healthcare, etc...
For USA salaries, that is. Junior devs average $62k in San Diego, California and would lose about 26% of that to tax, assuming they're single and without children.
The EMR EPIC is written (at least at its core) in MUMPS. They do the same thing as you describe above to get employees-hire young CS grads from 2nd tier schools straight out of college, and they use good starting pay and low cost of living (its based in Wisconsin) as a lure. Of course once people are there..there's no way out except resetting your career.
Epic is now working on switching to web technologies for the front-end, so if you're not one of the unlucky ones to be stuck on a purely core team, you'll get time writing Javascript and the like.
dear god...it's about time[1]...except I shudder to think what their concept of "the web" might be
[1]aside from being a long-suffering user of Meditech, I am also a long-suffering user of Epic, who had the misfortune of going through "mandatory Epic training" at 4 separate institutions that were transitioning to it from Meditech, or pencil and paper. I am still not sure which of the three systems were the most technologically advanced...
I find Epic to be more horrifying than Meditech, because Epic has somehow managed to convince many healthcare workers that it is a "modern" product worthy of praise, despite all evidence to the contrary. People talk about SmartPhrases like it's some miracle instead of a damn snippets manager (and a bad one at that).
The fact that they're moving away from VB6 to a web-based front-end in 2017 should be reason enough to assume that whatever they come out with is going to be excruciating.
I applied (and was offered) a job at EPIC out of college - their recruiters did not at all mention MUMPS or anything of the sort until I was on-site and explicitly asked some of the engineers interviewing me what languages they used. I remember them demoing some of the new features that were coming out in their EMR - "group by" support in sorting patients, etc. Not the most impressive features, and it completely crashed while they were giving the demo.
Great food, cool campus, and I really liked Madison - just not what I was looking for.
"resetting your career" isn't any kind of threat when the reset would start higher than their current situation.
More likely, there's no way out except resetting your life outside of that town in Wisconsin. And there really aren't that many good software jobs out there for the skill levels that accept jobs at Meditech/EPIC
> And there really aren't that many good software jobs out there for the skill levels that accept jobs at Meditech/EPIC
This assumes that everyone's skill level is fixed coming out of college, and that the interview process doesn't produce false negatives to let people fall through the cracks.
My first ever internship in software engineering (in 2012) was in the MUMPS world! I worked on a project for a contracting company building an automated testing framework (in python) to interface with and allow the VA to refactor their massive VistA EHR that was entirely written in MUMPS.
The fact that the system works at all is total magic to me, with hundreds of subsystems and millions of lines of code, all with the same shared global variable pool. I remember having to spend a few days digging through hundreds of pages of kernel documentation (it has its own kernel!) to simply find out how to write to a file..
What you can remember seems largely correct. I think commands and syntax were case insensitive, and variables were case sensitive too? All kinds of insanity like that.
Sounds like a job for Symantec Designs to get a translation from. Although I wonder if it would even be lucrative for them to specialize in an obscure language like this, but maybe!
When I was there a few years ago they were actively developing a new variant on one of their languages. They seemed to be going slightly more OOP to balance their functional paradigm out.
IIRC, this was a side project written by a friend of mine. He developed it in his spare time, due to his frustrations with MAGIC, and showed it off to enough people that they at least took enough interest to put some effort into it.
He's very much a Meditech lifer, and at this point may have been there for ~20 years at this point. From where he started, it was a big step up. Though what he could've done after his first 7 years at the place, I can only imagine, if he simply put in the effort to go anywhere else.
Ex employee of Meditech Minnesota here. Magic and its variants were pretty interesting to work with. The only reason I left was what you said, about experience being crippled by not having any standard languages under your belt working there.
Proprietary language concerns aside, it was fascinating using the tech there. Backend was Magic, as described by you and others. Direct B-Tree manipulation meant I didn't learn about the relational model but learned to reason about performance and indexing very directly.
The front-end language was what I found particularly fascinating though. It was concatenative, along the lines of Forth, and had some fairly powerful functional constructs, like a multi-part IF/Case where the first true expression would be returned to the outer scope.
Stuff was stringly-typed everywhere I remember, and with little to no safety on anything - I once found a bug where adding 1 to a list caused the ending delimiter to become something else and the list became unbounded in memory.
I worked at Meditech as well, there was also this one:
- Recursion was absolutely NOT ALLOWED because of 'the risk of crashes.'
Some more info on them (edit: added more as I remembered them)
During my last interview, they had me read my job responsibilities and then write an essay, in front of them, "in my own words" of what I would be doing. My future manager slowly walked around the perimeter of the room reading the essay while I sat in awkward silence. I still have no idea why this was necessary.
My salary was 38,000, my boss went home after my yearly review, then called my desk phone to say "money is tight this year" so I wouldn't be getting a raise.
There was a bonus you would get each Christmas which was a small percent of your yearly salary (5%?) which was compounded each year up to the last five years. Their first few weeks of training, they have lifers come in and openly brag about their yearly bonuses, which are only really impressive if you've been there for fifteen to twenty years.
One time the CEO came down to the cafe (they make food on-campus at most of their locations) to make an appearance, and magnanimously waved people through the line - he was paying for our lunches! Money being extremely tight as a new hire, I made my way through the line, but he had decided that he had paid for enough - he held up his hand and said 'sorry' and walked off. :(
Around the end of our training, the CEO had the latest batch of new hires head down to the auditorium where he gave us a speech reminiscent of cliche multi-level marketing summit speeches, and the only question asked afterward was by a really brave girl who asked him why our wages weren't competitive with the rest of the job market. He seemed really flustered and just answered "we think they're competitive, and if someone thinks they aren't, they're toxic and will no longer be employed here." I never saw her again.
> Meditech writes all of their own languages, databases, operating systems...The founder hated C with undying passion. No one is ever allowed to use C
Now you have my curiosity piqued. When I went to their Wikipedia entry [1], I saw that their server only runs on top of Windows. You said they run their own OS, so does that mean they effectively run an emulator of their OS on top of Windows? And if they hate C, does that mean MAGIC is self-targetable, or there is a very, very tiny chunk of C within Meditech, or that they develop in assembler to bootstrap their emulator?
An entire OS written in a Mumps dialect and a half-billion dollar company built around it (replete with an ecosystem of consulting companies) or TempleOS [2] vie in my mind for about the same uniqueness level.
Their oldest of three platforms was in its own whole OS, with a centralized server and command line remote access to it.
They then changed over to everything running as services under Windows servers, including a wacky append-only plaintext file system for audit logs.
I used to support their scanning and archiving stuff, which mostly meant fixing the horrible layers of Windows folder permissions on various Windows versions.
I previously used meditech on a daily basis, and good grief is it horrible. I've seen intelligent people spend 45 minutes just trying to figure out how to write a simple progress note before giving up and writing it by hand.
What's very frustrating is that no one - EMR vendors, hospitals, or even doctors - seem to realize just how much of a productivity booster good UX design can be. Even the ability to have multiple windows open at once (i.e. the ability to look at lab results while writing orders or a progress note) would be a breath of fresh air.
It's a marketplace designed to be exploited by shitty vendors.
You have the hospital administration that cares about billing first and foremost. Then you have doctors who have 500 lb egos and could give a shit about the computer systems.
All the company has to do is sell regional hospitals and the smaller practices will fall in line to more easily interact with the health network.
When my wife had our baby, we were in the hospital for a few days due to some complications. The OB nurses rolled around carts with two thin clients and two PCs on a KVM. There were seperate systems for charting, pharmacy, special OB charting, and something else. It was ridiculous.
Same story from the 90s: there was a company called IDX in Massachusetts (and Vermont) which sucked in many MIT recent grads. They were bought by GE healthcare. One person I know is still working there, making periodic trips to Burlington.
I think MUMPS was closely tied to VAX VMS at one point. I'm sure HP (Compaq (DEC)) still makes MUMPS money from OpenVMS.
I'm currently designing an [EHR system for my thesis](http://barnett.surge.sh/). I've been interviewing local GP's and healthcare professionals.
And holy hell, they hate medtech. They're actually quite happy with the functionality, but hate the interface. I had one nurse who went out of her way to contact them asking to make the smallest change, which would improve her job heaps - nearly a year later, no updates.
Thing is, these institutions are in a hard place. MedTech is shitty, but works, and changing to another system is such a huge task, why bother. Beyond that, if the majority of healthcare institutions are also in the same boat, so why go against the grain.
Healthcare software is weird man.
EDIT: I got meditech confused with medtech, my bad. Medtech still sucks.
I had to deal with Meditech for 9 years supporting the infrastructure requirements for a hospital group.
We had to fight to get them to agree on any improvements we wanted to make :
- virtualization
- support of vmware VMDK files instead of RDM
- support for non EMC arrays
- support for hyperconverged (nutanix)
- support for non EMC Networker or BridgeHead Backup
- DR process not using some proprietary software
- file archiving not using proprietary tool
version 5.x was a 3 tier application that looked like Windows 3.1
version 6.x no longer required 3 tier, not because they fixed it but just required you to run Citrix and UI was similar to GUI being put on top of AS/400 green screens (menu system) ... have a look here if you dare :) http://webapp.cchcs.org/tutorials/CBT/ADM/ADM%20Registration...
Apparently they are working on a SQL port and we advocated for years that they should focus on the business side using industry standard tools and languages.
I'm not hopeful tho as they wouldn't support things like Windows VSS and built their own tool, still had multiple single points of failures (20 "File Servers" aka the database backend and none redundant), issues with NTFS FAL fragmentation (and associated requirement to get a third party tool to monitor and fix) and the list goes on...
Moved on recently and only thing that looks good on the resume is, for people knowing Meditech, seeing all the changes we were able to push through ...
Oh and yes users were not big fans. All data entry needs to be entered in CAPITAL (no auto convert) so you need to caps lock when in Meditech and then remove the lock when switching to something like Word and the spacebar is a keyboard shortcut to select an item ...
And to really appreciated how bad it is, just search for "Meditech sucks" and read feedback from nurses ...
Back to the original post, I put MUMPS in the same category as COBOL ... useful a long time ago.
That's fascinating to hear. One of the key factors I heard that the EHR/EMR industry converged upon M is because patient records are sparse data efficiently represented in a key-value database, but which mapped inefficiently to SQL. The example given to me was a patient schema represented in SQL could literally have tens of thousands of columns/fields, of which only several hundred were used for each specific patient. Was the explanation given to me incorrect, or has the situation in the industry changed?
Never thought I would see a professor from my alma mater show up on the front page of HN! I could have maybe seen Dr. Wallingford (http://www.cs.uni.edu/~wallingf/) for his love of functional programming or Dr. McCormick (http://www.cs.uni.edu/~mccormic/) for contributions to ADA, but not Dr. O'Kane!
Took Database Systems from Dr. O'Kane. He was a pretty fun professor.
I took a look at the “Code examples from the book”. I haven't, ever, seen a nightmare like this.
Just one snippet from the User's Guide:
If you use a goto command, all do command pending returns
are canceled. That is if you invoke a section of code by
means of a do and the section of code executes a goto
command, the return to the line the do was on is canceled
as well as any other pending returns.
Yes, basic did better than that but you can actually 'goto' into some line in another subroutine in BASIC which can cause all kinds of interesting results (usually not the ones you intended though).
You can do the same with longjmp in C. You jump onto an empty stack, so you only have global variables to work with. It's fascinating, but not recommended :)
I worked at a company that used Mumps. They used some super-old interpreter that had a pretty low limit on the code size.
The actual size of the source code.
As the codebase grew, they had to shrink down the code to be able to fit it all in. Comments were the first to go. The end result was single letter variable and function names. The code was impenetrable!
Reminds me of how V8 used the length of a function's source code as a heuristic to decide if it should be inlined or not -> adding comments could slow down your JS. But of course JS already had code minifiers.
There was also a utility program that would take large source files and split them across multiple files. So you would end up with things like routine1_1.m routine1_2.m routine1_3.m and so on. Reading this with no comments and single letter variables and keywords was near impossible.
This page mentions the EHR used by the U.S. Department of Veterans Affairs, known as VistA[0], developed using MUMPS.
Interestingly, the source code for VistA has been obtained via FOIA requests and so the code is available in the public domain[1]. There are now forks of VistA, like OpenVista.
I used to work at Epic, where this language is used to implement much of the leading healthcare system in the United States. Many people there encouraged me to refer to it by different names like "M," "InterSystems Caché," "Caché," or even to my surprise "C."
I'm very, very happy to not be using this language anymore. After my first year on the job, I read some JavaScript code, and I nearly wept at how comparatively beautiful it was.
"Some of the contention arose in response to strong M advocacy on the part of one commercial interest, InterSystems, whose chief executive disliked the name MUMPS and felt that it represented a serious marketing obstacle. Thus, favoring M to some extent became identified as alignment with InterSystems."
Clever. By "built-in" I didn't mean just "available" as through an API to a third party library (which is a full blown DBMS in your first suggestion), I meant "integrated" as common types are (and lightweight)
Years ago at another company, we got acquired and had to port our shrink-wrap application from Oracle to Cache and support both. It was a horrible experience. The cache sales support guy bought our lunch a lot though. That's something.
As I understand it, M is the name used for the ANSI standardized version of MUMPS (ANSI X11.1-1995) and Intersystems Cache is a commercial implementation of that standard.
Lots of people called it Caché, but I don't think anyone would dare have called it C??
I found Epic MUMPS to be remarkably readable. Lots and lots of documentation, quite consistent coding standards, and although I would have preferred to write SQL queries rather than MUMPS routines, I didn't find it that abhorrent.
Mumps is everything a programming language should aspire not to be. It's worse than RPG, worse than MAPPER, worse than MIMER and all of those put together.
If a job description contains the word 'Mumps' and it is not in a sentence about your medical history: run like hell unless you are starving.
Source: was a Mumps programmer long long ago in a short stint at a bank that fortunately got bought out by another bank which had saner ideas about automation.
One fun fact: MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable.
"The M database is a key-value database engine optimized for high-throughput transaction processing. As such it is in the class of "schema-less", "schema-free," or NoSQL databases. Internally, M stores data in multidimensional hierarchical sparse arrays (also known as key-value nodes, sub-trees, or associative memory). Each array may have up to 32 subscripts, or dimensions. A scalar can be thought of as an array element with zero subscripts. Nodes with varying numbers of subscripts (including one node with no subscripts) can freely co-exist in the same array." [1]
I had to work with MUMPS once in the past when I was working in the green-screen world in healthcare. I also had to work with Pick/D3 and Basic. It was kind of nice to start there, then move to relational databases, and then see the world get excited again in older models of databases with the NoSQL movement (albeit, much more scalable and distributed).
> MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable.
Yep. And then there were the clustering primitives allowing you to modify variables on other machines. Which takes 'global state' to a wholly different level.
You thought it was problematic that a function could change a global variable as a side effect. Wait until you have to debug that global variable changing out from under your feet by a program running on a machine half the continent away.
Yeah, MUMPS was pretty prescient in this way. As someone who's experienced the changes first-hand, what do you feel are the most important NoSQL developments since MUMPS?
Do you have a preference on NoSQL vs relational databases?
The latest generation of NoSQL databases really tried to add to the distributed / scalability story of databases, as well as provide simpler "input", "output" and "storage mechanisms". This, often at the cost of a degree of ease of use of query languages to be able to easily analyze data.
As NoSQL movement started to come into focus, folks saw that the then dominant traditional relational / ACID model was not scaling to internet scale (too many JOINs, too hard to do ACID at that size or not needed, etc.). In reaction to "internet scale", the search turned to finding new or innovative alternatives to the relational model (which really, just represented what was the state of the art at the time). This is how we got BASE instead of ACID, and went back to key-value.. or document-oriented.. or graph-based... or Hadoop/Map-Reduce, etc. People exploring lots of alternatives.
I think people mentally "threw relational databases out" for a while as quickly as they threw out the other alternatives (the precursors to relational databases), when relational databases came along. Many have found it hard to live without relational databases.
I think modern NoSQL databases try to maximize on input/output/storage and distribution / MPP of data. By now, they give some more expressiveness for query (like MongoDB, Cassandra, Hive/Impala in the Hadoop world), although SQL still beats them in my opinion for ease of use. SQL also could have advanced as the query interface for those systems too, and if you look at the SQL:2011 standard, you'll see that it included methods for querying things that are distinctly "non-relational" (multivalue fields, etc.).
NoSQL databases also more cleanly map to object models, the dominant programming paradigm (although who knows, maybe one day that too shall change).
No, I don't have a preference of NoSQL vs relational databases in general. I believe they are complementary and maybe there isn't such a thing as a general purpose database for every use case. I do believe in the old saying, "try to use the right tool for the job". There are cases when a NoSQL database works superbly, and others where a relational database just feels right. For example, storing "objects" quickly works well with a NoSQL database vs. querying for a denormalized data warehouse seems to fit well into a relational database (ironically of course, since they are often denormalized and not third-normal-form 3NF).
Anyway, that's my take... but anyone else who has input should feel free to chime in.
I should also have said... they are all databases in the end. I try not to evaluate them based on the label (NoSQL, often a really bad labeling) and simply based on the problem faced and their features. Otherwise, you get lost in NoSQL vs. NewSQL vs. OldSQL vs. ___SQL.
Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day.
There are modern ANSI standards for the language, and several private vendors and open source implementations.
There are 2 things I like about M:
1. It has limited commands and is whitespace-aware
- Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. It's easy to memorize the standard library and easy to read code (because it's whitespace sensitive like Python).
2. The NoSQL database built right into the code
- You access the built-in, persistent database the same way you access regular data structures.
When setting values into an array you do something like "set foo(bar)=1". In order to persist that same data to disk, you just do set ^foo(bar)=1. This means less worrying about query languages and ORMs.
The database is a sparse B-tree structure so it's wicked fast at reads and writes. Great for a fast key-value store. There are people using M's battle-hardened NoSQL database with Node.js drivers, and you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance.
> Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day.
I know people that love working in COBOL. For the most part that is because it is what they know. Do you have extensive experience with other platforms/languages? How do you rate them side-by-side?
> and you're very unlikely to find a bug because it's been in production so long.
This goes for anything that's old. But that does not equate to 'good', it's just old. Just like new isn't necessarily better old isn't either.
And there are usually plenty of bugs in those codebases, just not in the runtime. But the user supplied code usually pre-dates any kind of automated (or even at all) testing other than 'try stuff and see if it produces the right results'.
The MUMPS codebase I worked on in the 80's was so fragile that deleting a single global string could cause the whole system to break down in ways that required a restore from backups. Don't ask me how I know that ;)
I'll second that unpopular opinion and claim I have experience with many other languages that I also enjoy.
The fun part about Mumps is that it's basically Lisp's ugly sibling, without meaningful scoping rules. You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly.
My single biggest complaint about Mumps codebases is that they're usually old, which means they have shitty documentation. Not that new ones are necessarily any better, but at least there's a chance new things are written in Orgmode or something :)
You probably won't believe it but this is actually very clean MUMPS code. If that's the shining example then you now have a bit of a glimpse of what the bad stuff looks like.
> For me, MUMPS is also related to some aspects of Erlang.
Superficially, yes. They're both old and they both have ways of hooking machines together at a distance built right into the fabric of the language.
But that's where all analogies end. A MUMPS program tends to be an unreadable mess to anybody who hasn't touched it in the last 30 seconds, whereas Erlang is really quite readable (though there are many people bitching at the syntax, this usually means they haven't spent any time with the language). Erlang projects tend to exhibit extreme levels of reliability and fault tolerance (and fault resistance) whereas MUMPS installations tend to be houses of cards that come crashing down with the first breath of wind.
You could not - outside of superficial similarities - find two architectures so diametrically opposed as MUMPS and Erlang.
> It's not the old part that he's praising but the fact that it's been extensively tested. That's definitely a plus.
Yes, but that 'plus' is largely negated by the huge minuses of the language itself to the point that you would probably produce something a lot more reliable by using something less battle tested and newer, and besides that there are other options that just as battle tested or even more so and better so why settle for less? (Erlang, for instance)
i actually like it as well. not too unpopular after all it seems. sure, some things are a bit ugly, and language development is largely controlled by a single company (intersystems), but especially working in healthcare you can't get around it. And it does certain things quite well.
1. Doesn't this make business logic quite a mess because normal and standard abstractions are missing? Won't new coders make horrible solutions to "reinvent the wheel" problems?
2. It would be trivial to implement a key-val data structure that is persisted to disk in almost any nice modern language. And there are very good No-SQL key-val stores to choose from that are backed by very large and credible industries.
The Node.js drivers. Are you sure those are not mainly due to legacy integrations rather than "we really just wanted to use the MUMPS db" ?
Sorry, I can't hop on board. My opinion is that implementing anything complex and new in ANSI MUMPS would be irresponsible given the better options available.
> It has limited commands and is whitespace-aware
Limited commands to a certain extent just means a more dangerous language. Being able to give functions private scope is something that's really important to me personally, as is having named constants, and objects with methods. About whitespace awareness, I consider it a fascinating design choice that the difference between one or two spaces between tokens within the same line of code can mean different things.
> Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures.
The language does not support first-class functions, but it does support the "xecute" command for running arbitrary code strings, which is particularly risky if you ever use user inputs as parameters in the strings you try to xecute.
Also, I primarily want knowledgeable developers working on my healthcare and financial systems, not the newer ones who would somehow be incapable of using a first-class function.
> wicked fast at reads and writes. Great for a fast key-value store.
This isn't a differentiating feature.
> you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance.
What happens when you need to change the code? Do you wait a long time until bugs are no longer found?
I think that fast reads/writes actually are a reasonably differentiating feature--if you want something like that in JS, Python, .... you're going to have to drop down to a C extension, and you'll have to put a lot of effort into that being portable. In a MUMPS interpreter, it's already there and it already works reliably.
The scoping issue I mentioned was function scoping, not variable scoping. The language would be better for organizing code if it supported functions as methods of particular classes of objects, or functions with private scope. As a codebase gets large, how well organized the code is makes a big difference in how easy and how risky it is to change things, so it really pays for your language to make code organization as natural as possible.
I am actually not able to find statistics matching up M databases with non-M databases at the moment, but I'd be interested in seeing something like that. I don't know what you mean about having to roll your own C extension to talk to your database.
A lot of what you're describing - in particular, "you access the built-in, persistent database the same way you access regular data structures" - was also true of many DBMS of the dBase era - dBase itself and its clones (Clipper, FoxBase/FoxPro), Paradox etc. But I think they still made better languages than MUMPS.
The biggest difference, it seems, is that instead of key-value stores, you had indexed tables. However, indexes were effectively key maps - there was no SELECT as in SQL (well, there was eventually, but not at first); instead you explicitly specified the index to use - unless you used the default index for that table - and performed a lookup, and it would position the current cursor for that table to the appropriate record. You would then access fields of that record as regular variables:
It might sound weird, but it actually worked really well for stereotypical CRUD form-based desktop apps - your cursor corresponds to the record currently being edited/displayed.
As an end user of a Mumps codebase, I like the speed (our interface is a VT-500 emulator over SSH to an OpenVMS machine), but the fact that there is no table-row-column database means pulling research extracts requires logging screen output to flat files, which then have to be parsed.
It's NoSQL, the early years. Trees with fast lookup capabilities. Useful for medical, which is basically tree-oriented. There's not much need for cross-patient access in medical records. A wide variety of data structured in different ways must be stored.
Umm, there are still plenty of "cross record" lookups--patients have standard types of encounters at the medical center, they take standard types of drugs, and have standardized billing/symptom codes. These are all references to other "tables".
MUMPS is older than SQL, so preSQL might be more appropriate than NoSQL.
There were moments of joy programming M, and the performance, scalability, and HA aspects of the Intersystems implementation don't hurt Epic one bit in the sales process.
At Epic, there are so many abstractions away from M that you might start to think you're working in another language. You never set globals in production code, instead using Epic's homegrown ORM to define schemas for your data.
At the end of the day, lack of first order functions and any other data structure other than the B-tree array makes for fun problem solving, but not necessarily clean and concise code.
It's funny, this is the first I've heard of Chronicles being called an ORM. I wouldn't really hesitate to call it a full database itself, written in M. But now that I think about it, I think you're quite on point there.
(You're telling me though you never came across "end-user" API-level code that was directly digging around in ^ER, ^ER1? Hahah)
Yeah smart people work at Epic, and smart people with ties to the midwest end up staying longer than 5-6 years. Epic does get a lot of things right, especially the code review process. If someone saw a reference to ^ER in code being committed, you can bet that it would get changed. The linter (HXPARSE) would actually prevent you from moving code with certain global references.
really? I think that depends on where you're at in the company. many touch M code on the daily, and while you don't set globals directly, I think ORM is generous for any of the systems that I know you are describing
Really? Did you ever create a new master file? Even an item? There are literally a million lifecycle hooks and item metadata properties available.
If Chronicles was open sourced tomorrow, it probably wouldn't make the front page of HN, but it is extremely feature rich tool that fits perfectly into the Epic ecosystem. That's true of most things that Epic develops.
I remember doing a MUMPS course in 1985. At the time my company was looking at replacing a PDP-11/45. One of the choices was VAX with MUMPS. We also looked at a GA machine with PICK.
181 comments
[ 2.9 ms ] story [ 61.0 ms ] threadI got a pretty persistent request to work on an informix 4gl system for a ridiculous rate. Haven't touched the stuff in years.
Most COBOL is cut and paste. One guy I know basically reads books and updates some report, where update means enter the next month and year combination into some code, entering a change request, and go to a change meeting.
He's basically working for 3 years until his wife can retire, then building a lake house.
http://thedailywtf.com/articles/MUMPS-Madness
http://thedailywtf.com/articles/Revenge-of-MUMPS-Madness!
Maybe the article would be better if he showed this more beautiful way of writing MUMPS?
</shudder>
It was about 3 years too long. Yes, that math is correct.
As far as I recall, MUMPS is essentially the dedicated coding language for a b-tree based database, and the only reason to ever use it for anything is for processing huge numbers of transactions through your NoSQL database every second, forever. I guess you also might want it if none of your employees knew how to correctly normalize a relational database.
Other than the nightmarish accumulation of technical debt continually rolled over since 1979, and the ungodly high turnover of people jumping ship after realizing MUMPS was a golden ball-and-chain, it was a pretty nice place to work. But management had a culture that it needed to force down everyone's throats, and the tech stack was a real resume killer. I still get contacted by recruiters desperate for MUMPS developers, and they make me feel like someone trapped inside a house besieged by zombies. I get really quiet, and hope they don't break any windows.
It only works because they throw a huge amount of money at it, and no one has any incentive to cheap out on medical management software.
Since I was more in their systems department I had limited opportunity to observe their archaic superstitions about code structure, but the short introduction course to M they provided confirmed that most current and new employees were willing to accept that certain control flow tools or function structures were dangerous because they were necessarily slower than something that made sense in hand assembly programming, since there had obviously been no developments in compiler optimization since M was designed (in the good old days, before C existed).
You weren't even allowed to touch the infrastructural M code. Mostly, you worked on superficial or peripheral M code, or on the GUI in VB6. I heard rumors of a GUI modernization team, but never saw any direct evidence of it.
It was a result of the iron grip of the top management. They didn't want to yield control of the company to the people actually running it. You were expected to use your expertise to do what you were told to do, in the best way you could, while still remaining completely within your lane.
After the 6 months of training, I gave it a year to read the character of the company, and then another 6 months to soak some potentially major family health care costs with that sweet insurance plan, then spent 4 months job hunting. It was the best employer-offered health insurance plan I ever had.
But make no mistake. Companies like Epic are why health care costs in the US are huge and growing. Epic never refactors anything that still works well enough to hold together with some expensive human labor. It is a technology company that runs on well-trained people instead of well-designed code and processes.
Some functional areas use Hadoop and SQL now. New server development can be done in VisualStudio using Typescript (which gets converted to M).
There are automated tools to set and verify OS parameters.
Most new installs are Linux now. No one uses VMS today. HP-UX and Solaris will be out of use in a couple years. InterSystems licensing is why people continue to use AIX (you have to buy new licenses to switch from AIX to Linux).
See the intersystems cache talk page on wikipedia: https://en.wikipedia.org/wiki/Talk:InterSystems_Cach%C3%A9
From what I can remember:
-Only global variables
-Variables must only be capital letters, maximum length 6. If you run out of variables, you must cleverly use them in a routine and set them back to what they are. This means you can't use a name like myVar - you use AAAFD, ZBVCXZ, etc.
-System functions are usually things like ., >, ', ], so code looks like .'AAAF]{\;:..
-Meditech writes all of their own languages, databases, operating systems, tools, etc. You can only write in a non-Meditech language if you get approval from a multi-tiered architectural design board, which barely ever happens
-The founder hated C with undying passion. No one is ever allowed to use C
-All programming hires go through a 6 to 12 month training process to learn the tools, languages, and systems. As they almost exclusively hire non-CS majors, such as math and physics majors, they don't typically have a programming background and don't realize how bizarre the MediTech stack is
Because MediTech engineers get experience in a proprietary suite of technologies that is only used there, it is extremely difficult for them to get new jobs at the same pay grade and experience level. 5 years at MediTech is worth 0 years anywhere else. However, I have hired a few of these people, and while they knew nothing about say Python, JS, Linux, etc. when hired, their deep understanding of how computers work made them very skilled once they picked up the modern technologies. Not many engineers program for years in low-level nightmare languages before touching JavaScript or Python, most start high-level and go lower. The foundation provided by working in a language like Magic makes them know computers at a deeper level than most.
I swear it was something insane like 36k a year in 2005. compared to 55k for GS . I asked them if it came with something to offset that like a pension or housing and they looked at me like I was crazy. I asked them to explain what they had to offer me and they made some stuff up about it being a great job with advancement potential. I think the word loyalty may have come up.
I didn't get an offer not that I would have said yes.
The lobby was nice as I recall. Lot's of open space, granite, and flowing water. Maybe that makes it worthwhile? Oh and you have to wear dress clothes. On 36k a year.
I'm sure it depends on geography and living cost but 36k is very low imo for a private company.
Public companies such as public university, government, and such still pay a bit above that on top of good compensations (healthcare, vacations, etc...).
This is USA of course.
France in general could be different in term of tax, healthcare, etc...
[1]aside from being a long-suffering user of Meditech, I am also a long-suffering user of Epic, who had the misfortune of going through "mandatory Epic training" at 4 separate institutions that were transitioning to it from Meditech, or pencil and paper. I am still not sure which of the three systems were the most technologically advanced...
The fact that they're moving away from VB6 to a web-based front-end in 2017 should be reason enough to assume that whatever they come out with is going to be excruciating.
but web doesn't necessarily mean modern in any sense of the word.
Great food, cool campus, and I really liked Madison - just not what I was looking for.
This assumes that everyone's skill level is fixed coming out of college, and that the interview process doesn't produce false negatives to let people fall through the cracks.
Those are both really unfortunate assumptions.
The fact that the system works at all is total magic to me, with hundreds of subsystems and millions of lines of code, all with the same shared global variable pool. I remember having to spend a few days digging through hundreds of pages of kernel documentation (it has its own kernel!) to simply find out how to write to a file..
What you can remember seems largely correct. I think commands and syntax were case insensitive, and variables were case sensitive too? All kinds of insanity like that.
He's very much a Meditech lifer, and at this point may have been there for ~20 years at this point. From where he started, it was a big step up. Though what he could've done after his first 7 years at the place, I can only imagine, if he simply put in the effort to go anywhere else.
Proprietary language concerns aside, it was fascinating using the tech there. Backend was Magic, as described by you and others. Direct B-Tree manipulation meant I didn't learn about the relational model but learned to reason about performance and indexing very directly.
The front-end language was what I found particularly fascinating though. It was concatenative, along the lines of Forth, and had some fairly powerful functional constructs, like a multi-part IF/Case where the first true expression would be returned to the outer scope.
Stuff was stringly-typed everywhere I remember, and with little to no safety on anything - I once found a bug where adding 1 to a list caused the ending delimiter to become something else and the list became unbounded in memory.
Awesome languages to write in, terrible to debug.
- Recursion was absolutely NOT ALLOWED because of 'the risk of crashes.'
Some more info on them (edit: added more as I remembered them)
During my last interview, they had me read my job responsibilities and then write an essay, in front of them, "in my own words" of what I would be doing. My future manager slowly walked around the perimeter of the room reading the essay while I sat in awkward silence. I still have no idea why this was necessary.
My salary was 38,000, my boss went home after my yearly review, then called my desk phone to say "money is tight this year" so I wouldn't be getting a raise.
There was a bonus you would get each Christmas which was a small percent of your yearly salary (5%?) which was compounded each year up to the last five years. Their first few weeks of training, they have lifers come in and openly brag about their yearly bonuses, which are only really impressive if you've been there for fifteen to twenty years.
One time the CEO came down to the cafe (they make food on-campus at most of their locations) to make an appearance, and magnanimously waved people through the line - he was paying for our lunches! Money being extremely tight as a new hire, I made my way through the line, but he had decided that he had paid for enough - he held up his hand and said 'sorry' and walked off. :(
Around the end of our training, the CEO had the latest batch of new hires head down to the auditorium where he gave us a speech reminiscent of cliche multi-level marketing summit speeches, and the only question asked afterward was by a really brave girl who asked him why our wages weren't competitive with the rest of the job market. He seemed really flustered and just answered "we think they're competitive, and if someone thinks they aren't, they're toxic and will no longer be employed here." I never saw her again.
Knowing the exact size of your stack statically is hugely important in safety-critical software.
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
This is plain incompetence on the "language" developers.
"When it is worth considering breaking up a monolith app into micro services?"
"About 1500 variables from now"
Now you have my curiosity piqued. When I went to their Wikipedia entry [1], I saw that their server only runs on top of Windows. You said they run their own OS, so does that mean they effectively run an emulator of their OS on top of Windows? And if they hate C, does that mean MAGIC is self-targetable, or there is a very, very tiny chunk of C within Meditech, or that they develop in assembler to bootstrap their emulator?
An entire OS written in a Mumps dialect and a half-billion dollar company built around it (replete with an ecosystem of consulting companies) or TempleOS [2] vie in my mind for about the same uniqueness level.
[1] https://en.wikipedia.org/wiki/Meditech
[2] https://motherboard.vice.com/en_us/article/gods-lonely-progr...
They then changed over to everything running as services under Windows servers, including a wacky append-only plaintext file system for audit logs.
I used to support their scanning and archiving stuff, which mostly meant fixing the horrible layers of Windows folder permissions on various Windows versions.
What's very frustrating is that no one - EMR vendors, hospitals, or even doctors - seem to realize just how much of a productivity booster good UX design can be. Even the ability to have multiple windows open at once (i.e. the ability to look at lab results while writing orders or a progress note) would be a breath of fresh air.
You have the hospital administration that cares about billing first and foremost. Then you have doctors who have 500 lb egos and could give a shit about the computer systems.
All the company has to do is sell regional hospitals and the smaller practices will fall in line to more easily interact with the health network.
When my wife had our baby, we were in the hospital for a few days due to some complications. The OB nurses rolled around carts with two thin clients and two PCs on a KVM. There were seperate systems for charting, pharmacy, special OB charting, and something else. It was ridiculous.
I think MUMPS was closely tied to VAX VMS at one point. I'm sure HP (Compaq (DEC)) still makes MUMPS money from OpenVMS.
And holy hell, they hate medtech. They're actually quite happy with the functionality, but hate the interface. I had one nurse who went out of her way to contact them asking to make the smallest change, which would improve her job heaps - nearly a year later, no updates.
Thing is, these institutions are in a hard place. MedTech is shitty, but works, and changing to another system is such a huge task, why bother. Beyond that, if the majority of healthcare institutions are also in the same boat, so why go against the grain.
Healthcare software is weird man.
EDIT: I got meditech confused with medtech, my bad. Medtech still sucks.
- virtualization
- support of vmware VMDK files instead of RDM
- support for non EMC arrays
- support for hyperconverged (nutanix)
- support for non EMC Networker or BridgeHead Backup
- DR process not using some proprietary software
- file archiving not using proprietary tool
version 5.x was a 3 tier application that looked like Windows 3.1 version 6.x no longer required 3 tier, not because they fixed it but just required you to run Citrix and UI was similar to GUI being put on top of AS/400 green screens (menu system) ... have a look here if you dare :) http://webapp.cchcs.org/tutorials/CBT/ADM/ADM%20Registration...
Apparently they are working on a SQL port and we advocated for years that they should focus on the business side using industry standard tools and languages. I'm not hopeful tho as they wouldn't support things like Windows VSS and built their own tool, still had multiple single points of failures (20 "File Servers" aka the database backend and none redundant), issues with NTFS FAL fragmentation (and associated requirement to get a third party tool to monitor and fix) and the list goes on...
Moved on recently and only thing that looks good on the resume is, for people knowing Meditech, seeing all the changes we were able to push through ...
Oh and yes users were not big fans. All data entry needs to be entered in CAPITAL (no auto convert) so you need to caps lock when in Meditech and then remove the lock when switching to something like Word and the spacebar is a keyboard shortcut to select an item ...
And to really appreciated how bad it is, just search for "Meditech sucks" and read feedback from nurses ...
Back to the original post, I put MUMPS in the same category as COBOL ... useful a long time ago.
That's fascinating to hear. One of the key factors I heard that the EHR/EMR industry converged upon M is because patient records are sparse data efficiently represented in a key-value database, but which mapped inefficiently to SQL. The example given to me was a patient schema represented in SQL could literally have tens of thousands of columns/fields, of which only several hundred were used for each specific patient. Was the explanation given to me incorrect, or has the situation in the industry changed?
Took Database Systems from Dr. O'Kane. He was a pretty fun professor.
Just one snippet from the User's Guide:
Even BASIC does better than that.Yes, basic did better than that but you can actually 'goto' into some line in another subroutine in BASIC which can cause all kinds of interesting results (usually not the ones you intended though).
Look at the documentation for the "shared" statement: http://www.leinweb.com/basic/manual/
It's a pretty nice language.
The actual size of the source code.
As the codebase grew, they had to shrink down the code to be able to fit it all in. Comments were the first to go. The end result was single letter variable and function names. The code was impenetrable!
Presumably this is no longer a limitation :)
Interestingly, the source code for VistA has been obtained via FOIA requests and so the code is available in the public domain[1]. There are now forks of VistA, like OpenVista.
At one point we had to argue with Github to support syntax highlighting for M/MUMPS: https://github.com/github/linguist/pull/148
[0] https://en.wikipedia.org/wiki/VistA [1] https://en.wikipedia.org/wiki/VistA#Usage_in_non-governmenta...
I'm very, very happy to not be using this language anymore. After my first year on the job, I read some JavaScript code, and I nearly wept at how comparatively beautiful it was.
"Some of the contention arose in response to strong M advocacy on the part of one commercial interest, InterSystems, whose chief executive disliked the name MUMPS and felt that it represented a serious marketing obstacle. Thus, favoring M to some extent became identified as alignment with InterSystems."
That's all the convincing I'd ever need. Though having a built-in optionally-persistent B-tree-based store sounds interesting.
SQLite will still perform better though, "heavyweight" SQL syntax notwithstanding.
I found Epic MUMPS to be remarkably readable. Lots and lots of documentation, quite consistent coding standards, and although I would have preferred to write SQL queries rather than MUMPS routines, I didn't find it that abhorrent.
If a job description contains the word 'Mumps' and it is not in a sentence about your medical history: run like hell unless you are starving.
Source: was a Mumps programmer long long ago in a short stint at a bank that fortunately got bought out by another bank which had saner ideas about automation.
"The M database is a key-value database engine optimized for high-throughput transaction processing. As such it is in the class of "schema-less", "schema-free," or NoSQL databases. Internally, M stores data in multidimensional hierarchical sparse arrays (also known as key-value nodes, sub-trees, or associative memory). Each array may have up to 32 subscripts, or dimensions. A scalar can be thought of as an array element with zero subscripts. Nodes with varying numbers of subscripts (including one node with no subscripts) can freely co-exist in the same array." [1]
I had to work with MUMPS once in the past when I was working in the green-screen world in healthcare. I also had to work with Pick/D3 and Basic. It was kind of nice to start there, then move to relational databases, and then see the world get excited again in older models of databases with the NoSQL movement (albeit, much more scalable and distributed).
[1] https://en.wikipedia.org/wiki/MUMPS
Yep. And then there were the clustering primitives allowing you to modify variables on other machines. Which takes 'global state' to a wholly different level.
You thought it was problematic that a function could change a global variable as a side effect. Wait until you have to debug that global variable changing out from under your feet by a program running on a machine half the continent away.
Do you have a preference on NoSQL vs relational databases?
The latest generation of NoSQL databases really tried to add to the distributed / scalability story of databases, as well as provide simpler "input", "output" and "storage mechanisms". This, often at the cost of a degree of ease of use of query languages to be able to easily analyze data.
As NoSQL movement started to come into focus, folks saw that the then dominant traditional relational / ACID model was not scaling to internet scale (too many JOINs, too hard to do ACID at that size or not needed, etc.). In reaction to "internet scale", the search turned to finding new or innovative alternatives to the relational model (which really, just represented what was the state of the art at the time). This is how we got BASE instead of ACID, and went back to key-value.. or document-oriented.. or graph-based... or Hadoop/Map-Reduce, etc. People exploring lots of alternatives.
I think people mentally "threw relational databases out" for a while as quickly as they threw out the other alternatives (the precursors to relational databases), when relational databases came along. Many have found it hard to live without relational databases.
I think modern NoSQL databases try to maximize on input/output/storage and distribution / MPP of data. By now, they give some more expressiveness for query (like MongoDB, Cassandra, Hive/Impala in the Hadoop world), although SQL still beats them in my opinion for ease of use. SQL also could have advanced as the query interface for those systems too, and if you look at the SQL:2011 standard, you'll see that it included methods for querying things that are distinctly "non-relational" (multivalue fields, etc.).
NoSQL databases also more cleanly map to object models, the dominant programming paradigm (although who knows, maybe one day that too shall change).
No, I don't have a preference of NoSQL vs relational databases in general. I believe they are complementary and maybe there isn't such a thing as a general purpose database for every use case. I do believe in the old saying, "try to use the right tool for the job". There are cases when a NoSQL database works superbly, and others where a relational database just feels right. For example, storing "objects" quickly works well with a NoSQL database vs. querying for a denormalized data warehouse seems to fit well into a relational database (ironically of course, since they are often denormalized and not third-normal-form 3NF).
Anyway, that's my take... but anyone else who has input should feel free to chime in.
There are modern ANSI standards for the language, and several private vendors and open source implementations.
There are 2 things I like about M:
1. It has limited commands and is whitespace-aware - Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. It's easy to memorize the standard library and easy to read code (because it's whitespace sensitive like Python).
2. The NoSQL database built right into the code - You access the built-in, persistent database the same way you access regular data structures. When setting values into an array you do something like "set foo(bar)=1". In order to persist that same data to disk, you just do set ^foo(bar)=1. This means less worrying about query languages and ORMs.
The database is a sparse B-tree structure so it's wicked fast at reads and writes. Great for a fast key-value store. There are people using M's battle-hardened NoSQL database with Node.js drivers, and you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance.
Check out Rob Tweed's work with M: https://robtweed.wordpress.com/2012/10/24/i-have-seen-the-fu...
I know people that love working in COBOL. For the most part that is because it is what they know. Do you have extensive experience with other platforms/languages? How do you rate them side-by-side?
> and you're very unlikely to find a bug because it's been in production so long.
This goes for anything that's old. But that does not equate to 'good', it's just old. Just like new isn't necessarily better old isn't either.
And there are usually plenty of bugs in those codebases, just not in the runtime. But the user supplied code usually pre-dates any kind of automated (or even at all) testing other than 'try stuff and see if it produces the right results'.
The MUMPS codebase I worked on in the 80's was so fragile that deleting a single global string could cause the whole system to break down in ways that required a restore from backups. Don't ask me how I know that ;)
The fun part about Mumps is that it's basically Lisp's ugly sibling, without meaningful scoping rules. You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly.
My single biggest complaint about Mumps codebases is that they're usually old, which means they have shitty documentation. Not that new ones are necessarily any better, but at least there's a chance new things are written in Orgmode or something :)
I'd love to see how it should be done, the only things I've seen are examples of how things (any things!) really should not be done.
I'm not really criticizing because I'm not sure there's an elegant way to do it, but I fled screaming.
Thanks for proving without a doubt that Mumps belongs in the trash can
……
Have you considered the possibility that you don't know M?
Forth is old too and some people love it.
Both MUMPS and Forth have some unique features:
- easy to bootstrap for Forth (mixing a compiler and interpreter)
- persistent and associative arrays for MUMPS
For me, MUMPS is also related to some aspects of Erlang.
Superficially, yes. They're both old and they both have ways of hooking machines together at a distance built right into the fabric of the language.
But that's where all analogies end. A MUMPS program tends to be an unreadable mess to anybody who hasn't touched it in the last 30 seconds, whereas Erlang is really quite readable (though there are many people bitching at the syntax, this usually means they haven't spent any time with the language). Erlang projects tend to exhibit extreme levels of reliability and fault tolerance (and fault resistance) whereas MUMPS installations tend to be houses of cards that come crashing down with the first breath of wind.
You could not - outside of superficial similarities - find two architectures so diametrically opposed as MUMPS and Erlang.
Seems to me it's a matter of how well it was written and the experience of the reader.
Kind of like other languages.
It's not the old part that he's praising but the fact that it's been extensively tested. That's definitely a plus.
Yes, but that 'plus' is largely negated by the huge minuses of the language itself to the point that you would probably produce something a lot more reliable by using something less battle tested and newer, and besides that there are other options that just as battle tested or even more so and better so why settle for less? (Erlang, for instance)
Have you ever used Erlang? If so, how would you compare MUMPS' tables to Erlang's ETS/DETS tables?
2. It would be trivial to implement a key-val data structure that is persisted to disk in almost any nice modern language. And there are very good No-SQL key-val stores to choose from that are backed by very large and credible industries.
The Node.js drivers. Are you sure those are not mainly due to legacy integrations rather than "we really just wanted to use the MUMPS db" ?
http://thedailywtf.com/articles/A_Case_of_the_MUMPS
> It has limited commands and is whitespace-aware
Limited commands to a certain extent just means a more dangerous language. Being able to give functions private scope is something that's really important to me personally, as is having named constants, and objects with methods. About whitespace awareness, I consider it a fascinating design choice that the difference between one or two spaces between tokens within the same line of code can mean different things.
> Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures.
The language does not support first-class functions, but it does support the "xecute" command for running arbitrary code strings, which is particularly risky if you ever use user inputs as parameters in the strings you try to xecute.
Also, I primarily want knowledgeable developers working on my healthcare and financial systems, not the newer ones who would somehow be incapable of using a first-class function.
> wicked fast at reads and writes. Great for a fast key-value store.
This isn't a differentiating feature.
> you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance.
What happens when you need to change the code? Do you wait a long time until bugs are no longer found?
I think that fast reads/writes actually are a reasonably differentiating feature--if you want something like that in JS, Python, .... you're going to have to drop down to a C extension, and you'll have to put a lot of effort into that being portable. In a MUMPS interpreter, it's already there and it already works reliably.
I am actually not able to find statistics matching up M databases with non-M databases at the moment, but I'd be interested in seeing something like that. I don't know what you mean about having to roll your own C extension to talk to your database.
The biggest difference, it seems, is that instead of key-value stores, you had indexed tables. However, indexes were effectively key maps - there was no SELECT as in SQL (well, there was eventually, but not at first); instead you explicitly specified the index to use - unless you used the default index for that table - and performed a lookup, and it would position the current cursor for that table to the appropriate record. You would then access fields of that record as regular variables:
https://msdn.microsoft.com/ru-ru/library/bz5ys9dy(v=vs.80).a...
It might sound weird, but it actually worked really well for stereotypical CRUD form-based desktop apps - your cursor corresponds to the record currently being edited/displayed.
MUMPS is older than SQL, so preSQL might be more appropriate than NoSQL.
There were moments of joy programming M, and the performance, scalability, and HA aspects of the Intersystems implementation don't hurt Epic one bit in the sales process.
At Epic, there are so many abstractions away from M that you might start to think you're working in another language. You never set globals in production code, instead using Epic's homegrown ORM to define schemas for your data.
At the end of the day, lack of first order functions and any other data structure other than the B-tree array makes for fun problem solving, but not necessarily clean and concise code.
(You're telling me though you never came across "end-user" API-level code that was directly digging around in ^ER, ^ER1? Hahah)
If Chronicles was open sourced tomorrow, it probably wouldn't make the front page of HN, but it is extremely feature rich tool that fits perfectly into the Epic ecosystem. That's true of most things that Epic develops.