At my first workplace we were using Digital Standard MUMPS on a PDP 11-clone (TPA 440), then we've switched to Micronetics Standard MUMPS running on a Hewlett-Packard machine, HP-UX 9, around early 90's.

Is still MUMPS alive? Are there anyone using it? If yes, please write some words about it: are you using it in character mode, does it acts as web server? etc. (I mean Caché, too.)

If you've been used it, what was your feelings about it? Did you liked it?

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

You needn't use the short form of commands, " D H S Y=%Y K %H,%Y Q ", you should write complete command names (and use longer label/variable names): "Do HourCount Set Year=%YearParam Kill %HourParam,%YearParam Quit". Also, after years of using short command form, I wrote a 20-lines program with usng long-form commands and long named variables. My collegues were told: "okay, it's a good joke, but don't do it again", it was 10 times harder to read than short commands.
–
ern0Sep 22 '10 at 7:59

Having been out of that world for a couple of years, my thinking is that the NoSQL movement is probably the best and worst thing to happen to MUMPS. Ultimately it's likely to both vindicate and kill it. Because somebody, at some point, is going to reinvent MUMPS's database and query structure almost identically, but with no connection to the MUMPS tradition. Then people will rave about this new storage system. But no-one will ever choose a MUMPS derivative again.

For example, a month or two ago, I was talking with a colleague about using redis to cache a look-up of something in our Django application. We had a large number of records addressed by a triple of three keys, and needed to quickly get subsets matching one or two of these keys (but different combinations at different times).

This is the kind of thing that MUMPS eats for breakfast. But we were finding it hard to squash into redis's key,val pair structure. Even with dictionaries. (Same would be true of memcached etc.) For the first time in my life, I found myself actually regretting that I couldn't write this module in Cache ObjectScript.

Funny interstar should mention Redis. I've actually reverse engineered almost all of Redis's behaviour using Mumps (both Cache and GT.M). Emulating its simplistic and basic key/value pair structure and APIs has been a piece of cake and the Redis clients I've tested don't even know they're talking to a Mumps database instead of the proper Redis.

However, like interstar says, the Mumps database is capable of so much more in terms of both its data structure (actually a Mumps database can easily emulate all 4 NoSQL database types: key/value, tabular, document and graph, and can also model relational and object dbs - all at once if needed), and the properly sorted out and automatic balance between in-memory versus on disk. Unlike the NoSQL databases that have been around for just a few years, the Mumps technologies are mature, tried, tested, well supported and have analytics and administration packages available, and have the kind of performance that many NoSQL databases such as CouchDB would die for.

So why aren't the vendors of Cache and GT.M promoting hard into the NoSQL market rather than let someone reinvent their wheel as you say?

As to the tired old bickering about the language and the use of that ancient and outdatad example from the Wikipedia site:

a) The Mumps database can be accessed by your pet sexy modern language of choice if you want

b) that style of programming went out with the ark, and was written at the time like that to squeeze amazing performance from PDP computers that had less processing power than the chip in your watch. Modern Mumps coding is actually very similar in style to Python and can be just as clean, readable and maintainable.

c) Like any language there are good examples you can find and terrible ones. Don't assume that Mumps coding needs to be as opaque and old-fashioned as the example on the Wikipedia site.

..and Mason, my conclusion would be that perhaps you aren't as familiar with the database landscape as you thought you were! :-) If you've had any form of medical treatment in your life, your information will have been through umpteen Mumps systems along the way, including ones that manage requesting of your tests. The contents of your daily newspaper may be managed by a Mumps system and even the pizza you ordered online was probably via a Mumps system too. The logistics of items you might have had shipped overseas was probably managed via a Mumps system, and if you happened to be a researcher who needed some fancy metals or ceramics, you'll have probably ordered them via a Mumps system.

One of the reasons you rarely hear about what is actually a surprisingly pervasive database is that the vendors have traditionally dealt directly with application/system developers rather than end users, so the database is usually embedded behind the scenes into products.

I think the language is not bad. I didn't tried but it must be pretty quick on a modern hardware. The latest version of MSM was supporting structured programming: local variables (New command), function parameters, inline subroutines for multi-lines. We were so happy with these features, and we've created a bunch of utilities: list viewer, menu etc. Finally, we ran out of stack, so we asked Micronetics to increase stack size. They compiled us a 32-deep stack custom version of MSM instead of the default 16-deep.
–
ern0Sep 23 '10 at 13:08

1

To push back a bit Rob, while I think the MUMPS db is worth paying attention to, I wonder if just the db, accessed from another language can still be called MUMPS. Anyone who chooses MUMPS expects to be able to run legacy code. So MUMPS, like it or not, equals the db + the language.
–
interstarSep 25 '10 at 1:44

2

As I mentioned elsewhere, the real disaster / dealbreaker for the language is dynamic scoping. I don't think any engineer, today, can justify choosing a language without local variables that stay local. So, by all means use the MUMPS db as a black box component, but the language is beyond redemption and should be put to rest.
–
interstarSep 25 '10 at 1:57

1

Mumps has full lexical scoping of variables - it has done for years, but a lot of people don't seem to have noticed! Mumps code can be just as clean and well behaved as any other language. In fact Mumps has a great many similarities to Javascript in terms of variable scoping. eg New in Mumps is, in effect, the same as var in Javascript. By default, however, variables are globally scoped in both languages.
–
RobSep 25 '10 at 13:21

1

Rob. I certainly didn't notice the lexical scoping of variables in Cache. What about my example in cachetastic.blogspot.com/2008/07/… ? That uses the "new" keyword, but is absolutely NOT the scoping rule you want. The x in f and the x in g should NOT be the same variable WITHOUT g having to explicitly hide any x that happened to be on the stack. The same thing converted into javascript, replacing COS's "new" with "var" correctly gives x in f as undefined.
–
interstarSep 26 '10 at 17:04

MUMPS is very much alive. It has been one of the most trust-worthy systems going in the proper hands. The programming staff is usually small and the up-time is impressive. It may seem to the uninitiated that MUMPS is obtuse, but it is possible to write very lucid and highly functional code in very few key strokes and the data structures supported by MUMPS make it extremely powerful and very transportable across various different architectures. All of the VA hospitals are using MUMPS and the mean-time-to-repair is very quick in most cases. The VistA system written in MUMPS is easily downloaded from Source Forge and the poly-modal nature (the database can be accessed by many ways, roll and scroll, thin client, browser, or RPC, or other program interface) of VistA and MUMPS comes through for many who delve into it. MUMPS is a simple language with very few commands and one data type. It is easy to learn because it is an interpreted language and leaves the stack and the symbol table intact to see exactly what was going on when the application stopped for debug. VistA has been used to run the Department of Defense hospitals (Composite Health Care System, CHCS) as well as the Indian Health Service (IHS RPMS), and the was once used by the US Public Health Service. It saved the country many millions of dollars in operational costs. MUMPS runs on nearly anything. It models nearly any other database model easily and provides surprisingly fast access to the databases. The MUMPS model can actually get faster performance with more users on the system (in some cases, due to the cacheing aspects of MUMPS where the pointer blocks needed to find a data block are already in memory and they don't need to be fetched again, BTW, the pointer overhead for MUMPS runs just about 2%, so most of your database is actual user data). MUMPS was originally written to run on a 2K machine. The onslaught of new technology has only expanded the full features of the MUMPS environment into a realm where whole hospitals are now being run on low-cost commodity servers. Early on, MUMPS divorced itself from the hardware and has benefited very well from that decision. We don't worry about the word size or the precision, or how many or how big. The database is late binding and grows as the specific record needs. No record in any database is any larger than it needs to be. The database can be expanded or pruned as per part of a record or as a whole record. Is MUMPS still around?, you betcha? An instead of getting 8 users on a PDP-11/34, you can get a couple of hundred users on the desk-top PC under your desk. It is being used in Banking, the European Stock Exchange, the travel industry (hotels and bookings agents), some auto parts houses, and most successful hospitals (commercial, private, or community) are running MUMPS in some form. The VA currently has over 30 years of outcomes histories for their over 9 million patients. That in itself is something that no other healthcare system has accomplished, except for Beth Israel/Deaconess Hospital in Boston that has over 35 years of outcome in their home built MUMPS system.

Why the downvote? The question was Is still MUMPS alive? Are there anyone using it? - surely this is relevant evidence of someone seriously writing new code and/or learning MUMPS?
–
Colin PickardApr 28 '11 at 16:57

f is a procedure which is invoked with a do. If, as in this case, it has no formal parameters, you don't need the (). A procedure just Quits and doesn't return anything.

g() on the other hand is a function. The new x is crucial to correctly scope x. A function is invoked by preceding its name with $$ and it QUITs with a return value. A function must have a formal parameter list declared even if it's empty as here. Actually you could write this instance of g() as just:

g()
quit 5

It will all behave perfectly now. For some reason a lot of Mumps developers don't seem to have noticed or understood the existence of functions, or understand the difference between them and procedures. I think this is one of the reasons why people new to Mumps throw their hands up in horror (not surprisingly) - there's an awful lot of terrible code out there.

Written as shown above, it's all quite clean and respectable stuff. However, it's up to the programmer to explicitly scope variables within functions and procedures. Leave them out and they'll be global and leak everywhere. The trick is to build and test each function as you go in isolation and ensure that they rely on nothing but their formal parameters and, when finished, they leave nothing behind.

Now one of the reasons you see Mumps code out there that doesn't use new commands and which relies on the variables being global (so it breaks if you New the variables) is because it was written at a time in the past before functions and lexical scoping were added to the language. Unfortunately there is a LOT of legacy code out there and, yes, it ends up being a nightmare to maintain, but that's legacy for you. On the other hand, it's quite possible to write clean, modern, well-behaved Mumps code, provided you're writing new stuff from scratch without any legacy stuff to worry about.
–
RobSep 26 '10 at 19:26

Looking at your original example, the value x, when new'd in procedure f is automatically available to g - that's just the way Mumps is. In the same way, people who are used to C-syntax languages are surprised when they discover that scope in Javascript is only applied to functions, and not, eg, to within loops or blocks inside a function. That's just the way it is - once you know it, you deal with it accordingly. Such idiosyncrasies have not stopped people accepting and adopting Javascript.
–
RobSep 26 '10 at 19:54

Rob : "Looking at your original example, the value x, when new'd in procedure f is automatically available to g - that's just the way Mumps is." Indeed! And that's what it means to say that MUMPS has dynamic scope and not lexical scope. In a lexically scoped language, you don't need to have the "new x" in function g, because the lexical structure of the program (ie. the fact that g is defined outside the definition of f), is sufficient to guarantee that the xs refered to in g and f are two entirely different variables.
–
interstarSep 28 '10 at 4:38

Rob. On the wider point, that a well disciplined team of MUMPS programmers, writing from scratch, and carefully using "new" to ensure that all variables are local, can avoid the pains of dynamic scoping. Sure, I agree. But why should we need iron discipline and hundreds of extra lines of code, to replicate what every other contemporary language gives you for free? Also, if you're faced with legacy code that wasn't written with this discipline, it's almost impossible to put it in later, because you can't tell if the system is relying on one of these non-locals to pass information around.
–
interstarSep 28 '10 at 5:09

There're other (older) methods to separate subroutine variables: all the variable names of system utilities begin with '%' sign, so they are in the "system namespace". Also, naming variables in New is about the speed: if you use an explicite command to push re-used variables onto the stack, the interpreter has to do nothing itself upon entering a routine. Also, you can use New, without parameters, which hides all the current variables.
–
ern0Sep 28 '10 at 5:21