Hacker News Reader

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.

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

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