Having worked heavily in MUMPS for almost 3.5 years at a previous job, I'd actually agree with MUMPS being a very productive environment. I think the main reason for this is that the semantics for working with in-memory and persisted data is identical, but still explicit due to the naming convention. This combined with the extremely limited language resulted in code that always was straightforward to read and modify as long as the previous author used decent variable names. I certainly wouldn't advocate for MUMPS, but I have been longing for something similar to its database access semantics since I stopped using it.

Do you consider Intersystems’ Caché to be a MUMPS? I ask because that stack us the worst I’ve ever used professionally. A syntax error borking the compiler can bork your entire runtime.

While we used Caché as our MUMPS runtime, it was policy to not use any of the language extensions in case we ever needed to switch to GT.M, so I can only speak to what is in the ANSI spec[1]. I never looked into the Caché functionality as a result, but it looks like if you used their ObjectScript then you definitely had a different experience than me. The closest thing to relational objects we had was that we had an internal standard for defining the structure of our globals (databases) such that they could be accessed and iterated over in a consistent way using an internal library of functions that made it kinda feel like working with tables; though even that was designed primarily to avoid bugs caused by simple typos. The vast majority of the code I wrote/worked with involved primarily for loops and basic CRUD with some locking code that was also simplified via an internal function library.

As for your syntax error woes, I don't recall ever running into a massive issue like that, but then again by the time I was working at this company they had decades of time to figure out a stable MUMPS dev environment and even an internal IDE for it, and for the most part they seem to have succeeded. I still wouldn't say I like MUMPS; if it had first class functions and the ability to use an entire tree as a return value (or at least a pointer of some kind) rather than only the value of the root node then I'd probably say I like it.

[1] http://mumps.sourceforge.net/docs.html

Surprising, isn‘t it?

Then again, maybe we should use data to inform our opinions (inform, not determine), rather using our opinions to filter out data?

Unfortunately much of the data about function points in programming languages is more or less random, because the 'data' was just a guess decades ago or based on obscure measurements done with unknown projects decades ago.

Take the number in table 16 from the cited paper for LISP. There is no explanation what this LISP actually is and what projects the 'data' comes from. One finds the same data in papers from two or more decades ago. There FLAVORS, an OO system from Lisp Machine Lisp from the 80s, gets a much different value. CLOS, the OO system of Common Lisp, gets another one.

These tables were in part computed/guesses from language variants which were looked at decades ago.

Thus without qualifying the numbers, the tables are for many languages just nonsense. The data behind it is weak and the conclusions are on shaky ground. This amounts to pseudo science.