[seanwoods]

You're referring to legacy MUMPS code. It's possible to write it more expressively (why do you think the examples on Wikipedia are like that?) People don't usually capture that nuance, sadly because many people don't care.

Yes, it's a bear to sift through poorly written MUMPS code. Yes, the language gives you more than enough rope to hang yourself. However, it's also possible to write code legibly and take advantage of abstractions that MUMPS provides (chiefly persistent arrays -- which are now ACID).

https://robtweed.wordpress.com/2013/05/24/making-mumps-accep...

[perturbation]

I'll second the above with a link to dlwicksell's node.js binding to M and the Intersystems version (Rob Tweed discussed the open source version by dlwicksell in the presentation):

https://github.com/dlwicksell/nodem

The Intersystems version: http://docs.intersystems.com/cache20122/csp/docbook/DocBook....

There could be some very interesting things done with this, using M as a NoSQL DB with javascript jquery-style abstractions for interacting with the DB.

[robtweed]

Indeed so - see http://gradvs1.mgateway.com/download/EWDLite.pdf

[brazzy]

The question is: if you're going to work with MUMPS, what are your chances of getting to write new MUMPS code rather than maintaining legacy code? And even if you write new code, how much of it is going to have to interface with legacy code.

I'm pretty sure the answers are "really slim" and "all of it".

[seanwoods]

At my company, we write new MUMPS code all the time. Some of this is sanely written ANSI standard MUMPS, some uses the Caché extensions.

There are techniques and strategies for containing legacy code which are pretty well known in the community. At minimum, this would involve wrapping it in a sane interface. You'd want to isolate global variable state too. Alternatively in Caché you can wrap it in classes (whose semantics are close to Java/.NET)

It's on our list to rewrite the legacy code "some day."