[rybosome]

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]

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.

[rybosome]

Thanks for the reply!

I agree with your points about weak typing and coercion being prevalent. Having had direct negative experience with it across 3 of the 4 languages you named, I was prepared to marshal an argument about it most definitely being a source of bugs.

> it should be obvious that this is a historical treatise

It wasn’t obvious to me. Might I suggest amending it to make that more clear?

I do appreciate the tutorial and your commentary though, it gave me a new perspective on MUMPS.

[benj111]

> the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing.

Is it a bad thing? Or is it different?

I literally spray brackets about because Im not sure of the precedence.

Explicit over implicit is generally regarded as a good thing. Why is there a blind spot when this comes to operator precedence?

[beagle3]

APL / K / J (and friends) evaluate things "left-of-right" (could be thought of as "right-to-left"), that is 1+23-4 is parsed 1+(2(3-4)) - there is no operator precedence. It is weird at first, but refreshingly simple and effective once you manage to overcome indoctrination you received since elementary school.

[benj111]

Well maybe it's just the stuff I do but even if you do something like 'address + offset * scale'

I still want to group that to make it obvious 'address + (offset * scale)'

The former technically works but it's less obvious. And that's a dead simple example

'address + offset << scale' is notionally the same but << has a lower precedence in c than + so you get the opposite behaviour so it's better to just bracket it out of habit.

I never find that I'm adding 3 random numbers. I'm adding 2 random numbers to make a meaningful value, then adding another number so a lot of the time I do 'foo + (bar + baz)'

Maybe if you're into pure mathematics you have a different take, but in my experience it's often the case that you end up bracketing most mathmatical operations for readability anyway

[beagle3]

What you seem to be saying is “I want no precedence or associativity - I just want explicit parentheses everywhere” which is a fine choice. But not a common one.

The reason APL made that choice (and its descendants followed) is that it had many tens of operators. There’s no intuitive or otherwise accepted order among them. Which means it’s either all parentheses (like you seem to prefer) or a simple rule (left-of-right). There’s basically no other solution.

Forth and Lisp also dropped precedence and associativity rules, each in their own way.