3 ms·
Since this is presented without context, and there's a significant chance people will get the wrong idea, I'm going to say this directly: The Mumps programming
by jimrandomh 9y ago
Since this is presented without context, and there's a significant chance people will get the wrong idea, I'm going to say this directly:
The Mumps programming language is widely used in the medical field, but it has a justified bad reputation. If you choose the Mumps programming language for a new project (as opposed to maintenance of an existing project where you don't get to choose the language), this is professional malpractice, and that goes double if the project is in any way safety-critical.
You have been warned.
- Fins 9y agoI'm certainly glad that I didn't have to touch any M in ages and ages, but there's a good chance that your medical records, your financial records, and possibly your telecom billing is stored with a good dose of MUMPS. And I heard people do use NoSQL for "important" data, and NoSQL is basically a reinvention of M as a square wheel and with no good parts of it.
- deleted 9y ago[deleted]
- cordite 9y agoHad experience with it. I'll give my goods and bads after about 3 years. Good: 1. Its behavior is very predictable, both in performance and for conditional behavior. 2. Error handling is not leaky, which helps with predictability. 3. Memory sharing is pretty isolated when it comes to processes / threads, much like erlang Bads: 1. If you want to do any sort of polymorphism or code reuse, consider yourself screwed. 2. It feels like assembly, everything ends up being tacked together and tangled for code reuse 3. What you write, and what you edit, and what you depend on will be long lived; version control blame will show code still running in production from before you even finished elementary school. Refactoring is impractical. 4. Event driven designs are nearly impossible to do in this environment. 5. Local environments are not a thing. You code in the same mainframe everyone else does. Good luck.