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.
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.
> 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.
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" ?
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.
Have you ever used Erlang? If so, how would you compare MUMPS' tables to Erlang's ETS/DETS tables?
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...