21–30 of 46 posts
Mumps! There's a couple of docker images floating around out there for playing around in it. If anyone hasn't tried it, it's "fun". M's global data stores, weird scoping, and strange syntax make for some interesting problems :P https://hub.docker.com/r/tsafin/fis-gtm-env/ https://github.com/KRMAssociatesInc/docker-vista
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 professio…
But I can't say for sure that it's entirely the fault of MUMPS rather than the amateurs who wrote the code. It literally was amateurs; they were doctors and interns, not professional programmers. They made a system that fit their needs quite well at the time, so they deserve quite a bit of credit, even though their source code is a nightmare by modern standards. Their story is recounted in the book Best Care Anywhere.
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 professio…
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.
Of the places I've encountered Mumps/Pick/Cache, there has always been that one gatekeeper guy - only he knew the arcane abbreviations and structure in his head, everyone else had to bow and scrape to get things done. Very good language if unmaintainable, arcane code and/or job security through obscurity is your thing. Cache even let it onto the web some years back I think with ObjectScript. Just wholly nasty. The po…
A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its invention: > Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read com…
That makes me think of TECO, where a string of commands resembled transmission line noise more than anything resembling program code.
The most TECO that I ever learned was how to invoke VTEDIT, and I forgot that a long, long time ago. :)
I suspect we would keep using it, except, last I heard, HP off-shored their OpenVMS maintanance to India and declared, in like 2011, that it would be EOL'd in 2017.
edit: I retract the statement that it's running on a PDP-11, though I have to say I was told that in teleconference just last month. I remember because it was shocking.
I am entering data and running queries on a MUMPS system right now, over SSH running OpenVMS 8.4. Last application software update: 1999. I suspect we would keep using it, except, last I heard, HP off-shored their OpenVMS maintanance to India and declared, in like 2011, that it would be EOL'd in 2017. edit: I retract the statement that it's running on a PDP-11, though I have to say I was told that in teleconference j…
2. OpenVMS is alive and well. It wasn't outsourced to India and it does not have EOL date. Currently it's being developed by VSI (https://www.vmssoftware.com/) and they're porting it to x86.
A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its invention: > Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read com…
Eh, as someone who's used it professionally, I wouldn't compare it to assembly. It's more like Awk - fairly concise for a good deal of its intended uses (linewise text manipulation for Awk, trees for MUMPS) and horribly clunky for most everything else.