Perhaps it’s because I’ve been around IT for quite a while: since the late 1970s in fact. Perhaps I’m just jaded and cynical. I’ve watched so many technologies come and go, and I’ve watched IT trends circling in and out of fashion. I’m sorry to say that most times when the “next big thing” coming along, I watch the new guys first really excited about it, watch it progress to either dying a death or becoming “mainstream” and therefore “safe”, at which latter point the management consultants start recommending it to their customers. Normally, throughout the process, I feel completely underwhelmed by the whole thing. What they’re all raving about is normally, in my opinion, nothing to get excited about.
Suffice to say, I’ve never been interested in technologies as fads or fashions, or as a means of furthering my career in IT. I’ve always been interested in technologies that are capable of doing what they really should the there for: allowing me and others to achieve more with less effort. Just like my colleague back in Hull University who first got me into programming in the first place used to say to me: at the end of the day I’m lazy. I really don’t want to be laboriously doing stuff that the damned computer can be doing for me instead – that’s its job! Yet, so often, I see technologies that require too much effort, require me to instruct the computer about what I want to do in far too minute detail, require me to state essentially the same thing over and over again in a ludicrously redundant way. Too many steps involved, too much work. I like instant gratification. I’m impatient and lazy. If there’s one thing I hate more than anything else, it’s writing more code than I think I should need to write.
A key reason for my excitement about Node.js was the timing. Taken in isolation, there’s maybe nothing too exciting, per se, I suppose, about Node.js. But my discovery of Node.js coincided with the peak of the early interest in the NoSQL movement.
In my opinion, the NoSQL movement was the best thing that could have happened and it was long overdue. For years – since the early 1980s in fact – “experts” in IT had deemed that the only database model worth giving any consideration to at all was the relational model. Anything else was looked down on as some antiquated and worthless idea that should have been confined to the IT dustbin of history years ago. This “mainstream” thinking, based more on fad, fashion and industry inertia than on technical merit, was one of the factors that kept the Mumps database technology in the shadows for several decades. Indeed, it’s a sad fact that many’s a great and highly efficient and effective Mumps-based application has been expensively ripped out and replaced by an underwhelming half-baked “mainstream” technology as a result of “safe” recommendations of a management consultant: “well there’s your problem – that old Mumps stuff. You need a proper database, mate. I’m a consultant guru who specialises in databases, and I’ve never even heard of Mumps, so go figure!”
So the NoSQL movement that burst onto the scene in 2009 came as a breath of fresh air. Suddenly the relational database was no longer king. Suddenly other database models were in vogue: key value, document, columnar, graph. An lo and behold, those same management consultants who, years earlier, had been responsible for chucking out Mumps databases, were starting to recommend to their customers that they really needed to be looking at NoSQL databases. The irony was, of course, that the Mumps database they’d been recommending to be replaced a few years earlier was, in fact, a truly great NoSQL database that had pre-dated the NoSQL movement by several decades (http://www.mgateway.com/docs/universalNoSQL.pdf).
So I saw the growing wave of interest in NoSQL as a great way of bringing the Mumps database – whose primary modern implementations are Caché and GT.M – back into vogue. There was a major stumbling block, however. Pretty much every other database, the new NoSQL ones included, are just databases, and are accessed via most modern computer languages. Mumps, however, has its own integrated language that is used to access and manipulate the database. Unfortunately, as I’ve discussed elsewhere in this blog (A Case of Mumps), mention the word “Mumps database” and very soon someone would poison the idea by pointing to numerous articles rubbishing the Mumps language. No matter how good or powerful the database, it was being subverted by opinion about its associated language.
Many who know Caché and GT.M will, of course, be thinking: but it’s been possible for ages to access the underlying Mumps database from mainstream languages. That’s true, and, for example, our own company has created numerous language bindings for GT.M as part of our MGWSI technology (eg PHP, Python, Ruby, Java, .Net) (http://gradvs1.mgateway.com/main/index.html?path=mgwsiMenu). However, in my mind, those “mainstream” languages have never quite gelled with the Mumps database – it’s difficult for me to put my finger on it and define properly what I mean: it’s more a gut feel I have about them.
I’ve done a lot of work in this area: I think it’s fair to say I pioneered the whole idea of integrating Node.js with Caché and GT.M. You’ll find my work on Github (https://github.com/robtweed). It’s proven to me that the combination is extremely potent and powerful. Probably the coolest thing I’ve managed to achieve in this area is to have persuaded InterSystems to include a native Node.js interface to Caché . Actually, that interface is the work of my colleague Chris Munt, but carried out on behalf of InterSystems. InterSystems first released it as part of their free Globals database (http://globalsdb.org/), but they’ve now made it available for their latest version of Caché.
The really special aspects of this Node.js interface to Caché are:
- it makes use of a very high-performance , low-level call-in interface to Caché’s global database engine;
These things add up to something very special, and something where the whole is definitely greater than the sum of its parts.
Whilst this ideal level of close integration is currently limited to the proprietary Caché, there’s no reason why a similar in-process interface couldn’t be built for the Open Source GT.M. I’m hoping someone will get on and do this. In my opinion this model represents the future for the Mumps technology: a super-fast, highly-scalable, ultra-flexible NoSQL database, accessed by the hottest and coolest, most trendy language out there. Instant gratification guaranteed.