by rybosome 4 hours ago

Quite agree.

Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it.

But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs.

The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.

In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.

Rochus 2 hours ago | [-0 more]

My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.