Ask a Mumps devotee to explain what he/she believes is its magic ingredient and you’ll get one or more of the following being highlighted:
- the easy-going interpreted language and its loosely-typed nature, which allows for rapid development
- the database which uses a concept and model known as Global Storage. This storage model and its impressive flexibility is described in detail in the “Universal NoSQL” paper that I co-wrote with George James.
- the fact that the language and database are tightly-coupled. Mumps is neither a language nor a database, but a combination of the two.
My analysis in part 1 of this article suggests that the rest of the IT industry have never recognised anything particularly special or noteworthy about these characteristics which I think is our (the Mumps community’s) fault, not their’s.
Let’s examine each of the three key magic ingredients of Mumps in a bit more detail:
If we look at the Mumps language, take out the parts that relate to the manipulation of the database and, unfortunately, you have a language that shows little other than its age. Whether the Mumps development community like it or not, the reality is that no modern developer will tolerate a language that is as simplistic, limited and old-fashioned as Mumps.
If we look at the Mumps database, I think that there has been a long-term problem in people “getting” Global storage. It seems a simple-enough concept and very powerful and flexible database model to those of us who have “got it”, but my experience of explaining it to others outside the Mumps development community is you either get back a blank look or a rapid dismissal that anything like that could ever be useful at all. To those that have never encountered Mumps Global Storage, the database model is a multi-dimensional associative array. For those of you familiar with PHP’s associative arrays, it’s effectively having the ability to store those arrays on disk rather than simply have them defined in memory.
Global storage is schema-free and completely dynamic. Nothing requires pre-declaration or pre-assignment. You just create, change and delete data within any level of the multi-dimensional arrays you want to access.
Unfortunately such a concept seems to not, in itself, be particular inspiring to developers outside the Mumps community, and I think it’s because such a unit of storage doesn’t seem natural, relevant or useful within any other language.
As I noted in Part 1 of this article, I think that timing has always been unfortunate for Mumps Globals as a database model. Non-relational database storage fell completely out of fashion at the very time Mumps was emerging, and by the time the NoSQL movement came along, the industry’s focus was on creating new, Open Source databases that could work well with the accepted modern languages. NoSQL databases rapidly differentiated into four main types:
- Key/Value storage (eg Redis)
- Columnar storage (eg Cassandra)
- Document storage (eg MongoDB)
- Graph storage (eg Neo4J)
The more generic Global storage model of Mumps, whilst flexible enough to be used to abstract all four of these NoSQL genres at once, suffers, I think, from being too non-specific and too generic for the new NoSQL generation to “get”.
However, the chameleon-like multiple personality of Mumps Global Storage is undoubtedly a unique and very powerful feature of Mumps Globals. Every other NoSQL database is a “one-trick pony”: optimised and good at only one of those four main types. If only Global Storage could be presented and made available to the new generation of developers in terms and in a way they could “get”, perhaps we’d be onto something.
Integrated Language and Database
The fact that Mumps is both a language and database at the same time has been both its strongest point and its most unfortunate and confusing feature.
A fully signed-up member of the Mumps zealot community know just how easy this integrated database and language makes the development of database applications. For example, I believe there’s no way that something as large and complex as the VA’s VistA application could have been developed using any other database technology and language using such a small development resource and in such a short time. It wasn’t because of the language per se, and it wasn’t because of the database per se, but because of some particular magic that stems from the fact that the language and database work together in such a slick and seamless way.
However, this tight integration of language and database has always meant that in order to get the best out of Mumps, you’ve had to use all its parts: ie you’ve had to learn its old out-dated language before you could get the benefits of the database.
In part 1 of this article, I mentioned that there have been lots of attempts to make the Mumps database accessible from other mainstream languages. I think this has never been fully successful for two reasons:
- language/database integration has never achieved the level of what I’d describe as intimacy that we see in Mumps
- Mumps Global Storage hasn’t been exposed to the language in a way that is natural enough for practitioners of that language to “get”
In fact, I now believe that it’s these two issues that are the key to understanding why Mumps has never taken off more widely and also the key to turning around the dangerously critical situation we now face.
I believe that the single most powerful feature of Mumps is a single little character that we Mumps developers have had sitting under our noses for all those years, that all Mumps developers use daily. Actually it’s not the character, but what it represents and its significance. I’m talking about the ^ symbol.
Mumps developers all know that the only difference between a so-called local array (think PHP-like associative array) and a Global is a ^ in front of the name. In other words, unlike pretty much every other modern database I can think of, a Mumps developer has an intimate and seamless relationship with the database. There’s no disconnect or clear line between whats in memory and what’s on disk. An in-memory array of data is created and manipulated in exactly the same way as an on-disk array of data: the only difference is a ^ in front of the array name which then denotes it as being an array that resides permanently on disk. There’s no explicit opening of the database, and nothing in the code that particularly says: at this point I need to fetch some data from the database or save some data back to the database. Disk access is implicit, not explicit.
Normally, then, a developer is explicitly moving data between database (ie disk) and language (memory) and back again.
Whilst you can do the same thing with a Mumps database, you also have this extra dimension of direct access to the database. You can literally poke around and touch the on-disk data in the database directly from the language in the same way you can touch the data that is in memory.
The natural representation of data for a Mumps developer is the so-called array, and the only difference between an in-memory array and an on-disk array is whether or not there is a ^ symbol in front of its name. It turns out to be an immensely powerful and liberating subtlety and I believe it’s the crowning achievement of Mumps and the key magic ingredient that needs to be introduced into a suitable alternative language.
The Phoenix Rises
So I believe we have the basic ingredients for a Phoenix to rise from the ashes of Mumps.
If the Mumps language itself is irretrievably dead, then clearly we need some other language to replace it: one that is acceptable in the eyes of the modern development community and one that ideally has all the same hallmarks that gave the Mumps language its edge in the eyes of Mumps developers.
Why can this approach succeed whereas so many attempts in the past have failed? I think that it’s the recognition of three key things:
If we can pull off such a set of tricks and create such a Phoenix, then we’ll have achieved two things:
None of this is speculative pie-in-the-sky. It’s all there, ready and available today. The Phoenix is ready to arise.