Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
Intersystems sell a MUMPS derivative : http://www.intersystems.com
Some of the most interesting people in MUMPS are probably here : http://www.outoftheslipstream.com/
I started blogging about Cache (the MUMPS derivative) a couple of years ago : http://cachetastic.blogspot.com/ (but then changed jobs)
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.
Some more thoughts on Cache here :
Good : http://cachetastic.blogspot.com/2008/07/ok-after-mentioning-some-bad-things.html
Bad : http://cachetastic.blogspot.com/2008/07/some-mumps-dissing-and-more-positive.html
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.
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.
there are a couple of serious mumps questions on SO:
Yes MUMPS is very much alive. A good portion of the VA Hospitals in the US use MUMPS.
VistA (Veterans Health Information Systems and Technology Architecture) is AFAIK still in active development: http://en.wikipedia.org/wiki/VistA_EMR
I am also new to g.tm, but I can answer this :
Yes, Mumps is alive. There are still people working on it. here are some examples :
http://georgejames.com/ who wrote an Openstreetmap api server in gt.m that I am learning now.
There are also now modern enterprise web tools for g.tm http://gradvs1.mgateway.com/main/
and the last proof that it is alive is that it has been ported to the latest GNU/linux and cloud platforms.
mike
One of the big companies working in medical records, Epic Systems, still uses MUMPS in their applications.
You should read this:
http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx
about MUMPS.
On the other hand, I work in the DC area and run into people fairly regularly that not only know what MUMPS is they work in it frequently.
Well, I have never ever heard of anyone using it, in any context or for any reason, except for on The Daily WTF. What conclusions can be drawn from this are up to the reader. ;)
Interstar's example correctly written to use functions:
f ;
new x
set x=$$g()
write x
quit
g()
new x
set x = 5
quit x
do f
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.
