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.
Thanks for proving without a doubt that Mumps belongs in the trash can
I'm not really criticizing because I'm not sure there's an elegant way to do it, but I fled screaming.
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)
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.
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 ;)