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 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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 ;)
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?
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" ?
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.
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.
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.
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.
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.
Obscure Mumps trivia: in the 80s, it was fashionable for the Brazilian Judiciary to build systems in M. (I have no idea why). Many courthouses and tribunals in Brazil are backed by large Mumps-based systems, not just for courthouse stuff but also HR and other purposes.
I worked as a civil servant in such a tribunal. Mumps was the first programming language I used professionally - in 2009! I wrote M for a living for around a year. It's still being heavily used in the place I worked at. My colleagues, who were more senior than I by a few decades, had written hundreds of thousands (millions?) of LOC in Mumps and developed a rich ecosystem of internal tools and libraries for it. It was a bit scary to do maintenance work on code that was written in the 80s, but I could often look at the author's signature and find out he was sitting right beside me - still pumping out Mumps. :-)
I can't say I loved the language, but it has some interesting concepts and reading about it makes me feel nostalgic.
Something weird about Mumps that I didn't see others mentioning here is how common it is for M programmers to abbreviate commands. Every command in Mumps can be abbreviated; "w" for "write", "i" for "if"; "s" for "set" and so on. This causes code to be extremely terse, and hard to understand for a beginner. A very simple example:
> I ($G(^ATM(1000))+$G(^ATM(500))+$G(^ATM(100)))<=0 D
> . W #,!,"There is no money available in this Machine. Sorry for the inconvenience."
> . Q
It gets way more complicated than that. After reading this kind of code for a few months, you get really good at parsing it.
>>It gets way more complicated than that. After reading this kind of code for a few months, you get really good at parsing it.
This must be how APL language users feel parsing their ultra-terse syntaxes (includes J/K/Q variants). Seems most applicable to quant shops that still use kdb+.
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 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.
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.
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)
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
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).
I work with M/MUMPS on a daily basis. It's no surprise that it is a primitive language, as it was developed in 1966 to run on PDP-7 computers, less powerful than a raspberry pi. But M is still very relevant today because it is the power behind many (most?) of the electronic medical health record (EHR) systems in the world: Epic, Meditech, VistA (from the VA), Allscripts (more here: https://en.wikipedia.org/wiki/MUMPS#Current_users_of_MUMPS_a...). Note that it is also extensively used in the banking industry. I have heard it said that at least 50% of people have their money run through a Mumps financial system during electronic fund transfers. Mumps is very fast and very stable, IMHO because of it's lack of bells and whistles. GT.M's version of Mumps is serious about it's moto of "Rock Solid. Lightning fast". (https://www.osehra.org/content/fis-gtm).
The most important part about any computing system/language is the resulting application. Yes, it is nicer for programmers when they have advanced language features. But ultimately, the test of how "good" a language is should really be about how useful it is, and how widely it is used.
The wheel is very old technology and yet still very important.
MUMPS (the programming language not the disease) found a niche in the medical world where it was developed. The name is an acronym for Massachusetts General Hospital Utility Multi-Programming System where it was developed. There is an ANSI standard for the language: see http://71.174.62.16/Demo/AnnoStd, for example.
I worked with the MUMPS Standard Committee trying make the language better while simultaneously trying to minimize the problems moving the large base of existing code to the new Standard MUMPS. MUMPS was filled with hidden gotchas. For example, in some early versions, trailing blanks in statements were significant.
The Wikipedia MUMPS article (https://en.wikipedia.org/wiki/MUMPS) provides some insight into the language and its genesis. The inclusion of a key-value store embedded into the language was a significant innovation and helped the language to be successful.
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.
My name has been mentioned a couple of times, so let me give my take.
Forget the Mumps language which always ends up being criticised for all manner of reasons, as witnessed here already.
Check out the database, however - it's the hidden treasure, which sadly gets overlooked and dismissed because of conflation with the Mumps language and its poisonous baggage.
You don't need the Mumps language to access the database. My work with it these days is in JavaScript/Node.js, using it purely as a multi-model NoSQL database, accessed in-process.
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 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..
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.
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.
All dynamically created on the fly - no need to define the array in any way ahead of time! The nodes are also automatically sorted after any addition/deletion.
Looping over the arrays is very easy too. M has a function that lets you set a variable to the next node.
Variables can also be created on the fly, and don't need to be defined as a type ahead of time. (Technically you don't define them ahead of time at all, if you want a new variable just set it to something!) They can be strings or numbers, and you can change their type at any time by setting them to a new value.
Pretty cool, and particularly easy for someone with no coding experience to pick up. I'd only ever use it for managing a database, though.
[+] [-] seibelj|9 years ago|reply
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.
[+] [-] Arkeband|9 years ago|reply
- 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.
[+] [-] arielweisberg|9 years ago|reply
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.
[+] [-] manifestsilence|9 years ago|reply
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.
[+] [-] bcaine|9 years ago|reply
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.
[+] [-] a2tech|9 years ago|reply
[+] [-] JusticeJuice|9 years ago|reply
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.
[+] [-] yourapostasy|9 years ago|reply
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...
[+] [-] _d8fd|9 years ago|reply
"When it is worth considering breaking up a monolith app into micro services?"
"About 1500 variables from now"
[+] [-] hdex|9 years ago|reply
- 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.
[+] [-] northern_lights|9 years ago|reply
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.
[+] [-] jhallenworld|9 years ago|reply
I think MUMPS was closely tied to VAX VMS at one point. I'm sure HP (Compaq (DEC)) still makes MUMPS money from OpenVMS.
[+] [-] ridiculous_fish|9 years ago|reply
[+] [-] z3ugma|9 years ago|reply
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...
[+] [-] jacquesm|9 years ago|reply
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 ;)
[+] [-] rnprince|9 years ago|reply
> 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?
[+] [-] elnygren|9 years ago|reply
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
[+] [-] rnprince|9 years ago|reply
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.
[+] [-] Clubber|9 years ago|reply
[+] [-] __float|9 years ago|reply
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.
[+] [-] jdboyd|9 years ago|reply
[+] [-] ajmurmann|9 years ago|reply
[+] [-] paxcoder|9 years ago|reply
That's all the convincing I'd ever need. Though having a built-in optionally-persistent B-tree-based store sounds interesting.
[+] [-] jacquesm|9 years ago|reply
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.
[+] [-] rmsaksida|9 years ago|reply
I worked as a civil servant in such a tribunal. Mumps was the first programming language I used professionally - in 2009! I wrote M for a living for around a year. It's still being heavily used in the place I worked at. My colleagues, who were more senior than I by a few decades, had written hundreds of thousands (millions?) of LOC in Mumps and developed a rich ecosystem of internal tools and libraries for it. It was a bit scary to do maintenance work on code that was written in the 80s, but I could often look at the author's signature and find out he was sitting right beside me - still pumping out Mumps. :-)
I can't say I loved the language, but it has some interesting concepts and reading about it makes me feel nostalgic.
Something weird about Mumps that I didn't see others mentioning here is how common it is for M programmers to abbreviate commands. Every command in Mumps can be abbreviated; "w" for "write", "i" for "if"; "s" for "set" and so on. This causes code to be extremely terse, and hard to understand for a beginner. A very simple example:
> I ($G(^ATM(1000))+$G(^ATM(500))+$G(^ATM(100)))<=0 D
> . W #,!,"There is no money available in this Machine. Sorry for the inconvenience."
> . Q
It gets way more complicated than that. After reading this kind of code for a few months, you get really good at parsing it.
[+] [-] otoburb|9 years ago|reply
This must be how APL language users feel parsing their ultra-terse syntaxes (includes J/K/Q variants). Seems most applicable to quant shops that still use kdb+.
[+] [-] doughj3|9 years ago|reply
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...
[+] [-] epmatsw|9 years ago|reply
[+] [-] comice|9 years ago|reply
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 :)
[+] [-] detaro|9 years ago|reply
[+] [-] bebop|9 years ago|reply
[+] [-] tempodox|9 years ago|reply
Just one snippet from the User's Guide:
Even BASIC does better than that.[+] [-] tsomctl|9 years ago|reply
[+] [-] mcknz|9 years ago|reply
http://thedailywtf.com/articles/MUMPS-Madness
http://thedailywtf.com/articles/Revenge-of-MUMPS-Madness!
[+] [-] nwhatt|9 years ago|reply
[+] [-] nwhatt|9 years ago|reply
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.
[+] [-] __float|9 years ago|reply
(You're telling me though you never came across "end-user" API-level code that was directly digging around in ^ER, ^ER1? Hahah)
[+] [-] DanielFallon|9 years ago|reply
[+] [-] sixdimensional|9 years ago|reply
"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
[+] [-] kdtop|9 years ago|reply
The most important part about any computing system/language is the resulting application. Yes, it is nicer for programmers when they have advanced language features. But ultimately, the test of how "good" a language is should really be about how useful it is, and how widely it is used.
The wheel is very old technology and yet still very important.
[+] [-] drallison|9 years ago|reply
I worked with the MUMPS Standard Committee trying make the language better while simultaneously trying to minimize the problems moving the large base of existing code to the new Standard MUMPS. MUMPS was filled with hidden gotchas. For example, in some early versions, trailing blanks in statements were significant.
The Wikipedia MUMPS article (https://en.wikipedia.org/wiki/MUMPS) provides some insight into the language and its genesis. The inclusion of a key-value store embedded into the language was a significant innovation and helped the language to be successful.
[+] [-] cartothemax|9 years ago|reply
Took Database Systems from Dr. O'Kane. He was a pretty fun professor.
[+] [-] robtweed|9 years ago|reply
Forget the Mumps language which always ends up being criticised for all manner of reasons, as witnessed here already.
Check out the database, however - it's the hidden treasure, which sadly gets overlooked and dismissed because of conflation with the Mumps language and its poisonous baggage.
You don't need the Mumps language to access the database. My work with it these days is in JavaScript/Node.js, using it purely as a multi-model NoSQL database, accessed in-process.
Check out what can be done with it here: http://ec2.mgateway.com/ewd/ws/training.html
In particular check out the multi-model capabilities of the database and the JavaScript-orientated abstractions that are possible - see parts 17 - 27.
Some may also find this interesting: https://github.com/robtweed/ewd-redis-globals
[+] [-] mdekkers|9 years ago|reply
[+] [-] moomin|9 years ago|reply
[+] [-] briffle|9 years ago|reply
</shudder>
[+] [-] logfromblammo|9 years ago|reply
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.
[+] [-] nradov|9 years ago|reply
[+] [-] NetStrikeForce|9 years ago|reply
That's the summer I decided I didn't want to be a programmer.
[+] [-] gameshot911|9 years ago|reply
Ex:
All dynamically created on the fly - no need to define the array in any way ahead of time! The nodes are also automatically sorted after any addition/deletion.Looping over the arrays is very easy too. M has a function that lets you set a variable to the next node.
Ex. (using the above example):
Variables can also be created on the fly, and don't need to be defined as a type ahead of time. (Technically you don't define them ahead of time at all, if you want a new variable just set it to something!) They can be strings or numbers, and you can change their type at any time by setting them to a new value.Pretty cool, and particularly easy for someone with no coding experience to pick up. I'd only ever use it for managing a database, though.