Hacker News Reader

> 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 ;)

I'll second that unpopular opinion and claim I have experience with many other languages that I also enjoy.

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've yet to see a MUMPS code base that would qualify as 'elegant', do you have any pointers?

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.

I witnessed a DSL for querying a MUMPS database. It used MUMPS to parse a DSL, generating more MUMPS to then query the MUMPS db.

I'm not really criticizing because I'm not sure there's an elegant way to do it, but I fled screaming.

https://github.com/robtweed/EWD/tree/master/m_apache

I hope that wasn't meant sarcastically?

No, it wasn't.

This mess makes perl look readable

Thanks for proving without a doubt that Mumps belongs in the trash can

You probably won't believe it but this is actually very clean MUMPS code. If that's the shining example then you now have a bit of a glimpse of what the bad stuff looks like.

> I know people that love working in COBOL. For the most part that is because it is what they know.

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.

> 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.

I have no experience with Erlang, and about 30 years with MUMPS. Some MUMPS can be hard to read, and some is not.

Seems to me it's a matter of how well it was written and the experience of the reader.

Kind of like other languages.

>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.

It's not the old part that he's praising but the fact that it's been extensively tested. That's definitely a plus.

> 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)

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?

You can have variable scoping, just use `new`?

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.

The scoping issue I mentioned was function scoping, not variable scoping. The language would be better for organizing code if it supported functions as methods of particular classes of objects, or functions with private scope. As a codebase gets large, how well organized the code is makes a big difference in how easy and how risky it is to change things, so it really pays for your language to make code organization as natural as possible.

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.

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" ?

http://thedailywtf.com/articles/A_Case_of_the_MUMPS

A lot of what you're describing - in particular, "you access the built-in, persistent database the same way you access regular data structures" - was also true of many DBMS of the dBase era - dBase itself and its clones (Clipper, FoxBase/FoxPro), Paradox etc. But I think they still made better languages than MUMPS.

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.

i actually like it as well. not too unpopular after all it seems. sure, some things are a bit ugly, and language development is largely controlled by a single company (intersystems), but especially working in healthcare you can't get around it. And it does certain things quite well.

> You access the built-in, persistent database the same way you access regular data structures.

Have you ever used Erlang? If so, how would you compare MUMPS' tables to Erlang's ETS/DETS tables?

Do you by chance work for Epic?