The MUMPS 76 Primer – anniversary edition • Hacker News Board

Re: The MUMPS 76 Primer – anniversary edition

#61

Post by tancop » Tue, Jun 30, 2026, 8:32 AM UTC

Rochus wrote: post #10

sgerenser wrote: post #9

Earlier quoted context omitted.

I don't think anyone is really blaming MUMPS for the limitations it had to work with 1970s tech. The story was more about how terrible it is to work with in the 2000s and the surprising fact that it's still in use today in certain niches.

My project and the referenced primer are about the 1976 standard. But many MUMPS based systems are still in operation and maintenance today; and not many significant systems in IT reach a 50 year lifetime. A modern JavaScript, PHP or Python system (languages with similar limitations for large-scale software engineering as MUMPS) written five years ago hardly works today because dependencies significantly changed or a…

> A modern JavaScript, PHP or Python system written five years ago hardly works today because dependencies significantly changed

thats why the best practices are version locking and containers. your dependencies cant change from under you when its pinned to a specific hash. the only way it can break is if npm or pypi shuts down and nobody including you has an archive which is extremely unlikely.

and you can run a oci image in 50 years unmodified unless linux stops development decides to break userspace and theres no working translation layer for the next system. even if it becomes obsolete the spec is still there and someone will build a "docker on future runtime X" if they need it.

Re: The MUMPS 76 Primer – anniversary edition

#62

Post by benj111 » Tue, Jun 30, 2026, 9:33 AM UTC

beagle3 wrote: post #60

benj111 wrote: post #51

Earlier quoted context omitted.

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

APL / K / J (and friends) evaluate things "left-of-right" (could be thought of as "right-to-left"), that is 1+2 3-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.

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

Re: The MUMPS 76 Primer – anniversary edition

#63

Post by beagle3 » Wed, Jul 01, 2026, 7:23 PM UTC

benj111 wrote: post #62

beagle3 wrote: post #60

Earlier quoted context omitted.

APL / K / J (and friends) evaluate things "left-of-right" (could be thought of as "right-to-left"), that is 1+2 3-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.

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

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.