All I want for Christmas

Since they are both variations of the Mumps database and language, comparisons between Caché and GT.M are inevitable.  The major difference is that GT.M is unapologetically a pretty straightforward pure Mumps implementation with few added frills: the philosophy is that if you need extra functionality than provided by the raw Mumps environment, you can easily and efficiently pop out to the operating system and/or people can write and distribute value added Mumps-based functionality.  Our EWD product is a good example of the latter.

By comparison Caché aims to provide a complete playground, albeit a walled one (in licensing terms): you really don’t need to go outside the Caché environment as InterSystems have directly integrated everything they believe you probably need, including:

  • an object orientated projection of the underlying database
  • simultaneously, a relational projection of the underlying database
  • object orientated extensions to the language (referred to by InterSystems as Caché ObjectScript)
  • SQL extensions to the language
  • report writing tools

It makes for a very attractive and very functional package, but of course the big thing that GT.M has in its favour is that it’s an Open Source product.

Personally, I find that GT.M has most things I need, but then again I focus on the web application and web service areas and have included in EWD all the key capabilities needed for those environments, such as XML DOM, XPath, JSON mapping, HTTP Client etc.  Everything else can be done in and provided by Javascript, particularly when you use Node.js (I’ll be talking more about the marriage of Node.js and Mumps in a future posting).

And so to the title of  this posting. Whilst there’s not that much I personally find missing in GT.M (now that I’ve added all that stuff inside EWD), there are two things that, for others, are crying out to be addressed:

  • an Open Source SQL interface (plus an inclusive projection layer on top of the raw Mumps global storage).  This should ideally include an industry-compliant ODBC interface.  Being able to access Mumps database via SQL would be a huge boon for the many people for whom it’s the de facto means of accessing databases.  There are solutions available for GT.M: KBSQL, which I understand to be an excellent product, but  unfortunately it’s a proprietary product; and PIP from FIS (the owners of GT.M), but my experience is that PIP is unfortunately way too complex to be usable by most Mumps developers.  Until such an Open Source SQL interface becomes available, the best I can suggest is for SQL-oriented developers to check out Chapter 2 of  a document that I and my colleague Chris created some years ago:  http://gradvs1.mgateway.com/download/extreme1.pdf
  • GT.M (and of course Caché) is a highly capable NoSQL database.  However, no self-respecting NoSQL database these days is deemed complete without a Map/Reduce query interface.  I don’t believe it would be particularly tricky to implement this on top of Mumps global storage using the Mumps programming language.

Those who know me will know I  do have one other wish: for someone to port GT.M to the Raspberry Pi (http://www.raspberrypi.org/).  How cool would it be to have a complete Open Source Mumps environment, complete with EWD and the Node.js gateway all running on $25 worth of hardware?  It could probably run a complete VistA system too!  A perfect platform for the next generation of developers to discover the amazing talents of my favourite technology.

So, dear Santa, any chance do you think?

 

Advertisements

3 comments

  1. Look at Ray Newman’s MUMPS V1 on the Raspberry Pi.

    http://www.mumpster.org/phpBB3/viewtopic.php?f=13&t=1706

  2. Ray – indeed so, and great work. But there’s a problem – Mumps V1 adheres to the original standard and lacks the “modern” language features that Cache and GT.M have both adopted that, in my opinion, are essential to making it acceptable as a language in 2012. Specifically:

    – long variable names (up to 31 characters, mixed case)
    – long routine labels
    – long global names
    – long routine names

    EWD, for example, depends on these. WIthout them, its public APIs would end up looking like arcane gibberish. A bit, unfortunately and with all due respect, like the Mumps code examples that end up being pilloried and bring Mumps into such disrepute.

    Fix those deficiencies in Mumps V1 and I’ll have EWD on the Raspberry Pi like a shot

    Rob

  3. I think this article really sums up why I believe it’s vital to get GT.M running on the Raspberry Pi and therefore in front of the next upcoming generation of developers:

    http://www.guardian.co.uk/technology/2012/nov/04/raspberry-pi-programming-jam-cern

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: