rob.tweed's blog

Mumps is dead? Long live Mumps?

I've been doing quite a bit more thinking recently about the role, position and future of Mumps, particularly based on issues raised in the many blogs I've been reading. There's a lot of naive and uninformed bashing of Mumps, particularly with respect to its role and relevance in healthcare, and also in terms of its role in the modern world.

So I thought I'd pull together some thoughts and provide a fairly in-depth analysis.

Firstly, and crucially, we need to separate out the two components of Mumps: the database and the language.

The database is actually an interesting beast. It's a schema-less hierarchical database engine: characteristics which are coming back into vogue, as witnessed by the likes of Google's AppEngine, Amazon's simpleDB and Apache couchDB. This style of database is being driven by the demands of the so-called Internet-scale database. See:

and, for our analysis with respect to the Mumps *database*, see:

With GT.M providing a free open-source implementation of the Mumps database engine (, I believe that there's great merit in the kind of modern developers who are being attracted by this style of database taking a look at just what the Mumps database engine is capable of. For some background on the Mumps database and how you can use it, see our paper at:

In the "olden days", a lot of the bad press encountered by Mumps was due to its closed nature, its lack of a schema and the associated inability to apply SQL to search the database. Now let's be clear about two things:

1) this was originally due to restrictions in the Mumps *language* which used to be the only way in which you could interact with a Mumps *database*.

2) these days the Mumps database is much more readily accessible, eg:

- InterSystems have added object/relational projections, allowing the core Mumps database to be queried by their embedded SQL and also (and crucially), allowed their objects to be accessible natively from within the more modern mainstream languages such as C++, .Net and Java. Additionally, their web gateways (the result of pioneering work by our company) allow both the Cache object/relational projections *and* any legacy Mumps database records to be accessible via a browser interface, allowing much of the client-side scripting to be written using Javascript.

- our own company's gateway technology (MGWSI) further allows the Mumps database in both Cache and, perhaps more interestingly, GT.M to be fully accessible and integrated with any modern mainstream scripting language: eg Java, .Net, C++, PHP, and, in our next forthcoming release, Ruby, Python, and Perl.

So, in fact, the reality is that there is no reason why the very interesting features and capabilities of the Mumps database can't now be explored and experienced by a modern generation of programmers using their favourite pet language.

It is absolutely true that the Mumps *language* can appear very cryptic and arcane to an outsider, and unfortunately it's a language in which it very easy to write unmaintanable code - another of the themes that has come up in this debate. With the move away from the old "green screen" days to client/server and, more latterly. web/ajax applications, there's actually very little need to write much in the way of Mumps code any more - most of the scripting is done in other languages. Most of my work, for example, is now in the Javascript domain. So the statement "it’s widely-regarded outside of healthcare IT that MUMPS is relatively unmaintainable compared to modern languages/platforms" is true only if you're talking about applications written entirely using the Mumps *language*. Modern healthcare applications written using Cache or GT.M rely very little on the Mumps language.

Let's move to a second issue:

Something that comes up time and time again in these debates is the suggestion that it's about time that Healthcare abandoned the old fashioned Mumps technology and that something more modern and maintainable was used for applications in healthcare. I wish people who harp on about this would actually examine and ponder the track record of previous attempts to migrate from Mumps to something more modern and mainstream. The fact is that in over 25 years of watching these attempts, I'm not aware of a single one that's been successful, despite the best endeavours of some of the biggest names in IT armed with, in some cases, astronomically large sacks of cash. You need only look at the embarrassingly snail-like rate of progress within the UK's NHS IT Strategy where they're all still waiting for the much vaunted replacements products. They're years behind schedule and there's a trail of some very large companies who have become casualties in this multi-billion pound exercise. eg see:

Now discussion of this issue normally descends into another futile debate about whether or not there must be something inherently different about the data within healthcare that makes the Mumps database suitable and the RDBMS unsuitable. My opinion is that this is far too naive an argument. I believe there's a lot more to it than this, but I'd summarise the situation by saying that the demands within the healthcare environment have an interesting similarity to those being experienced in the Internet-scale arena. For example:

- healthcare IT projects have a terrible habit of suffering from scope drift, often due to changing statutory requirements for data collection as political strategies related to healthcare come and go during the development of the applications. Suddenly that originally nice and tidy database schema needs a bunch of other stuff added to it. This is certainly an area where the schemaless databases come into their own and one of the features that Amazon promote for simpleDB (see the paragraph titled "Flexible" in Conversely it can play hell with an RDBMS implementation.

- cost-effective scalability: Healthcare systems for an entire metropolitan area have to be extremely large, with high peak loads and the need for high performance by busy healthcare professionals. Whilst it's possible for the mainstream RDBMS's to be scaled up to vast sizes and deliver high performance, it requires a *lot* of hardware, expensive licenses and DBAs. In many cases it's just not a cost-effective solution for the highly budget-conscious healthcare community.

- rapid development: Healthcare systems are far from simple in scope. They include a lot of functionality, and if systems are to be delivered speedily to the healthcare community, that requires extremely rapid development. I have to say, based on experience of working on all kinds of languages and platforms, the mainstream view of what constitutes rapid development is a long way removed from what I've seen possible in Mumps and Cache. I think that forms part of the great frustration of Mumps devotees: they see great claims being made about the latest and greatest new technologies in terms of their abilities for rapid application development, but they seem like a sad joke compared with what they know they've been able to achieve with their old Mumps stuff. Why this should be so is beyond the scope of this discussion, but something worthy of further analysis elsewhere. Anyway the result is that even the fastest mainstream rapid development techniques prove inadequate, so development just ends up taking too long.

So, the net result is that it's clearly not as simple as the many IT consultants, advisors and pundits would have us believe. It's not as simple as just getting rid of that old Mumps stuff and rewriting those applications in something more modern and maintainable. If it was that simple, that old Mumps stuff would have been long gone, but it's still there, and there in droves. In my opinion a lot more people should be analysing in more depth just why such an apparently anomalous situation should exist, and comparison with the Internet-scale database requirements goes some way to explaining it.

The third issue that I've seen discussed relates to the lack of a thriving community ("the weak MUMPS ecosystem"). This is an interesting one. I totally agree that one of the great problems is the dearth of people creating value-added features and libraries of modules and until recently I was of the belief that it was a terminal problem, but now I'm not so sure. I think it is partly a historical/timing issue. The great emergence of massive thriving communities has really been a result of the Internet, and therefore a phenomenon of the last 10 years. That coincides with exactly the time when all but one of the original Mumps implementations was bought out by InterSystems and buried into their proprietary Cache product. I think it's fair to say that InterSystems are a company that likes to tightly control and determine the use of their product, and I think as a result, there's been little incentive for third parties to create a wealth of add-odd products. It's also greatly limited because Cache is not a free, open-source product.

Now the interesting factor is GT.M. It was a somewhat unusual implementation of Mumps and never had a particularly big following. So when InterSystems snapped up the other vendors, it acquired most of the then Mumps developer community as users. most of whom would have found the GT.M implementation just too different for their liking and comfort.

Since then, a couple of things have happened. GT.M has been released as free open-source, around about the very time when the demands of Internet-scale databases are causing people to look beyond the relational model. And of course we have the Internet which can, as we've seen with Ruby, allow an explosive growth in a hitherto little-known technology.

Contrary to the views that I see expressed about the future for Mumps, I therefore believe that conditions are now pretty much right for a new-found interest in it. Not, I suspect, in the Mumps language, but I believe there's a great opportunity for a new community to emerge, discovering the potential of the Mumps database, and adding value, features and libraries to the free, open-source GT.M Mumps database engine to fill in its deficiencies etc. Our company has already provided the gateways that open it out to the mainstream languages, and I would love to see new people discovering the potential of the Mumps database as a persistence layer for their particular language.

Will this happen? Let's wait and see. I would love to see it happen and there's great treasures for new people to discover. The kind of things I can do with ease, speed and simplicity in Mumps would be a real eye-opener to a great many of the new kids out there.

EWD Training at Bletchley Park

As you'll see from the programme, I'll be running an EWD training stream at Out of the Slipstream in Bletchley Park. What I'd be interested to know is what level of training would people like. There are essentially 3 options:

1) a beginners introduction to EWD, so you'll be able to see what EWD is all about, what it does, how it works etc

2) an advanced introduction to custom tag development (which is where you can really get control over EWD)

3) an introduction to the ExtJS and Emprise Javascript Charts widget tags in EWD

Unfortunately with Out of the Slipstream being a one-day event, it's impossible to fit more than one course into the time available. So what would be your preference?

You can let me know on the day, but it would be more useful to know in advance what you all think: add your votes as comments to this thread.

Many thanks

The Web Application is dead! Long live the Web Application!

If you're attending InterSystems' Devcon in a few weeks time (, make sure you visit the M/Gateway Developments ( booth at the Partners Pavilion. If you weren't considering attending, then maybe you should reconsider!

What we'll be announcing and demonstrating is nothing short of the new face of the web application, a set of technologies and capabilities that will fundamentally challenge opinions and preconceptions of the limitations of browser-based application. What's more, we'll demonstrate that EWD makes such a quantum shift unbelievably simple to implement.

The unique and hugely powerful EWD paradigm is now set to seriously challenge the conventional approach to web application development. Come and see the future of web applications, and discover how quickly and simply your applications could become a part of that future.

EWD's Dojo Widgets: the bigger picture

On the face of it, the recent Dojo extensions to EWD may just appear as a way of grafting on a cool set of industry-standard UI components, but if that was all the story, it would imply that if you need fancy widgets when you use EWD, then you have to use the Dojo ones. In fact that's not the case at all. There's a lot more to the exercise than immediately meets the eye.

One of the primary motivations behind the exercise was to create a working demonstration of how to build a set of EWD Custom Tags that would automate and simplify the use of a third-party set of widgets. So let's look a bit more behind the scenes, because, with some outside participation by you, the readers, EWD could become exceptionally powerful: even more so than it is already.

Javascript frameworks and widgets in particular are a very interesting area because you can tap into huge amounts of work that has been already done for you in the design, usability and cross-browser support of these often highly complex components. There are many of them, all of them free to use, including:

- Dojo (, of course. The "grand-daddy" of them all, but notoriously complex to use, often buggy or highly sensitive to being used "just right", and historically at least, extremely badly documented.

- ( A very popular widget set, if you can sift through the (IMHO) apallingly laid out web site and find something you'd like.

- Yahoo YUI ( Some very nice widgets here from a major force in the Javascript world, with gurus such as Douglas Crockford behind what they do. Their widgets require a lot of Javascript coding in your pages.

- Interface Elements for JQuery ( Not so well known, but wow! Their widgets are beautiful!

- Backbase ( An up-and-coming force in the Ajax world, again with some extremely sexy widgets, and a very interesting XML-based underlying methodology.

Of course you could spend the time to figure out how to use any one of these libraries and manually hand-craft the widgets into standard EWD pages. That, in itself, is an important feature of EWD that should be understood: there's nothing in EWD that prevents you using any or all of these Javascript libraries. Having said that, most of the libraries have, at their core, a set of solutions for handling the "round-trip" Ajax plumbing (based around the use of the browser's XMLHTTPRequest object) and data binding. These are superfluous if you use EWD: it already contains its own proven built-in solutions.

There's several problems with manually hand-crafting third-party widgets into your EWD applications:

- first, you need to understand the mechanics of the Javascript library you're using. That means a lot of effort, ploughing through their documentation, trying out examples, tweaking them till they do more the kind of stuff you'd like to do. Without exception, all the libraries have a steep learning curve and despite their goal of making it simple to do complex things, they are complex environments to create and use. Dojo is a particularly complex beast.

- secondly, how do you decide which library to use? To do a thorough comparison would take way too long for it to be commercially viable. Can you cherry pick and use one widget from Dojo and another from Backbase? No, it's usually an all or nothing commitment to one, you invest time and effort understanding it and then you're tied to it for better or worse.

- thirdly, the code you typically have to embed in your pages to make the widgets work is, quite honestly, horrendous. One of the most important principles of EWD is that your pages should clearly describe WHAT your pages are trying to do, leaving EWD to generate HOW they do it. Whilst Javascript libraries certainly make it a lot easier to implement complex UI widgets, nevertheless they are still necessarily pretty low-level beasts. Hand-craft them into your EWD pages and a year from now I can guarantee that you'll be scratching your head trying to figure out what they're all about if you need to maintain a page containing them. Worse still it probably won't be you maintaining the page. The result will typically be what I've seen so many times and despaired: it becomes quicker and easier to rewrite the page from scratch than figure out how the old version works. That this is tolerated at all is unbelievable, but my observation based on 12 years experience in this world is that, sadly, it is the commonplace state of the art!

So where's this leading? Well EWD has a secret weapon up its sleeve: EWD pages are actually an abstraction of the pages you'll really run within the environment of your choice. They have to be compiled down into the run-time version that will run on PHP, CSP, JSP or whatever. This is how EWD allows you to have the best of all worlds and describe your pages in terms of what they do: the compiled pages that EWD's compiler generates are all about HOW they actually work, chock full of all kinds of nasty run-time-specific stuff that you'd otherwise have to hand-craft yourself. EWD's XML DOM-based compiler performs the transformations from your high-level tag-based description in your EWD pages into the nasty run-time stuff in, say, your PHP pages. You never really need to look at all that PHP (or CSP, JSP etc) code. If you need to modify or maintain a page, you just modify the high-level EWD page and recompile.

The other secret weapon within EWD is its Custom Tag architecture. All of EWD's own built-in custom tags were implemented using this, and, from the start, the architecture has been exposed and available to the end user to craft his/her own Custom Tags. At the heart of an EWD custom tag is its "tag processor": a method you design to transform an instance of your XML-based custom tag into whatever it needs to be expanded into in the run-time page. You describe that transformation as a set of XML DOM manipulations on your EWD page. This is exceptionally powerful stuff. There really is no limit to the complexity of the transformations you can carry out. And to make matters even better, your transformation can make use of EWD's own custom tag primitives, leaving them to look after the technology-specific aspects, so your Custom Tag will automatically work in PHP, JSP, CSP or whatever!

And so back to those Javascript libraries. My implementation of the Dojo tags was a case study in how to design and express the use of a set of complex third-party widgets as a set of very easy to use EWD Custom tags. I hope you'll agree when you look at the source code in the Dojo examples I've made available on our web site, the EWD/Dojo Custom Tags are all about describing WHAT you want to do: eg I want to have a slider at this point in my page. EWD's compiler and my Dojo tag processors look after converting this to the nasty mass of Dojo tags and Javascript logic that needs to be embedded in your page. Apart from idle curiousity, you'll probably never need to know or care how it's actually done at the Dojo level.

As a result, anyone can now use the Dojo tags without really having to spend any time ploughing through the reams of Dojo's documentation and examples. That steep learning curve has been removed and you can quickly give Dojo a go. And of course a year from now, anyone can pick up that page and see that you used a Dojo slider at that point in the page and tweak its behaviour as required.

And so to where I'm trying to lead this discussion. What I've done is provide a template of how a third party widget set can be expressed as a very simple-to-use set of high-level EWD Custom Tags. It's not intended to be interpreted as a lock-in to Dojo in any way. Quite the opposite. What I'd like to now see is the equivalent implementation as EWD Custom Tags of as many of the Javascript libraries out there as possible. My problem is time. It takes a significant effort to do this. The main effort is actually getting to grips with and understanding the way you use the Javascript library and all its subtle nuances (eg the most complex part of the Dojo implementation was figuring out how it could work with the Ajax fragment replacement mechanism in EWD). The actual custom tag processor development, once you're familiar with DOM processing, is pretty trivial. For example the Dojo FishEye menu custom tags were written on a Sunday afternoon whilst also cooking the dinner!

So there's my request to you, the reader. I'm seeking volunteers to help implement all the major Javascript widget libraries as EWD custom tags. I'll provide as much assistance as you need to understand the mechanics of how to go about such a task. For example, I'm thinking of running an in-depth seminar on Custom Tag creation during DevCon if anyone's interested.

The rewards to the community will be immense. What we'll then have, within the Cache/GT.M community is, without any argument at all, THE most powerful and flexible Ajax/Web 2.0 development environment on the planet. Anyone will be able to use whatever widgets they like without any of the steep learning curve and maintenance nightmares. Users of EWD will be able to focus their efforts where they really should be focusing their efforts: on their application's functionality, concentrating their efforts on WHAT their applications do, rather than fiddling around wasting time and effort on HOW their applications need to do it! EWD + Cache or GT.M will be demonstrably THE most productive web/Ajax development environment, bar none.

Volunteers please? Contact me at if you want to help in what I believe will be one of *THE* most influential projects for our community.

Syndicate content