Caché: FTW!

A colleague emailed me this link to an article, which depicts a mostly accurate picture of MUMPS technology stigma. Being a life-long programmer myself of several languages, SDKs, APIs, and other assorted tools, I believe I can speak objectively about MUMPS as a programming language and as a career path. But be warned! If you ARE programming in an environment solely based on 10-years of obsoleted MUMPS or M technology — talk to your boss about change, consider switching careers, or suck it up and live with it for possibly another 10-years.

The article is accurate that the surviving healthcare information systems (HIS) that were incubated using MUMPS in the 1970s are now colossal in terms of size and support — you would think so after thirty-something years. And yes, some of the original programmers are still working those colossal HIS today — and they have learned to use it cleverly — but imagine the architectural creativity you would develop if you played in a consistently growing sandbox for over 20-years? While I do agree those programmers are now insane, I do not subscribe, as it is suggested, that it is a result of any MUMPS limitations. Do you know of ANY programmer that has made a “professional career” by actively using BASIC, COBOL, .NET, PASCAL, or RPG for 30+ years? 20+ years? 10+ years? 5+ years? I might be able to scrape up a JAVA programmer or two with 10+ years.

However, Bryan’s case of the MUMPS is likened to some evil version of a Venus Fly Trap. That is pure shit. Bryan’s objectives were framed with “getting a job”, with the false hope that it will magically lead to some “glamorous career in software development”. Having instructed computer programming at the college level, I believe Bryan (and maybe the article’s author) are misguided that one can make a fabulous career using Microsoft Access and FrontPage. Because if Bryan was truly concerned with his career path, he would have had a plan before filling out job applications. In all of my work experiences, regardless of industry, if you “pay your dues” you will get “what’s due”. But while I am deeply passionate about my work, I accept that for most developers, it is a job with only the material rewards as a metric for success. As with any career in IT, after all, it is mostly a thankless job.

My case of the MUMPS

IMHO, MUMPS, like the many other programming languages invented after it, became obsolete when client-server application development took over mainframe / server-centric software. During that span in the 1990s, MUMPS was in danger of going the same dead-end route of BASIC, PASCAL, and RPG. Just as Microsoft’s BASIC became Visual BASIC, and Borland’s PASCAL became DELPHI, so did InterSystems’ MUMPS get extended with Visual M. Just not entirely successful as Visual BASIC. Ok, Visual M was a disaster. Programming in Visual BASIC using an ActiveX component to make remote procedure calls or store/retrieve data from a UNIX or VMS proprietary MUMPS server… talk about a software development and IT support nightmare. It is of no wonder that the client-server paradigm died a slow and painful death.

In the mid-1990s, emerging technologies like Netscape web servers and browsers, JAVA, and even Borland’s CORBA started the changes and challenges with the client-server paradigm. While Microsoft nearly missed the Internet back when it was only a wave, the software giant nimbly embraced web application development (and naturally implemented their proprietary extensions). Unfortunately, with no other titan to challenge Microsoft, out went its competitors: Netscape entirely, JAVA acceptance was slowed, and where is Borland today anyways? In its place were the tormented years of worms and viruses that spread from the ActiveX and Javascript exploits, running amok on already fragile servers using software in what is known as DLL hell. From Microsoft’s “participation” in the dot com era spawned not an improved end user experience and satisfaction, but an array of security and anti-virus companies with their associated products to combat the countless millions of ailing systems and desktops. I sincerely do not complain about it, because I also made a lot more money from that technological shoddiness coupled by executive management short-sightedness that made the costly trek.

But back to MUMPS, unlike those other programming languages that have failed to survive client-server, Visual M mutated into something better: it became a uniquely open application and database development product, dubbed Caché. Now, I am no fanboy of InterSystems, particularly their lame buzz phrases, like “World’s first post-relational database” and “No DBA required.” But Caché succeeds by improving upon MUMPS — without eliminating its long established ANSI standards — extending on top of what was a closed, procedural-style language into something that allows the developer to implement as much or as little of its object-oriented paradigm. Not only were objects added to MUMPS syntax, but it was also integrated into its database engine to maintain object persistence. No other standalone “language” can claim that kind of integration between code and data. JAVA and .NET require the use of some external technology to provide for their object persistence, such as SQL Anywhere, Hibernate, or db4o. And implementing those interfaces lead to real reliability, scalability, security, and support concerns — all of which can be then happily purchased, installed, trained, configured, and supported to cover up those deficiencies with yet another layer on the application software stack. Are you kidding me??

But Caché did not stop by being the best all-in-one Swiss army knife of programming and database technologies. Caché grounds itself firmly to be an open system by interconnecting with all those “standard” languages and databases, allowing them as near native access to its native objects — both code and data. Caché provides ODBC and JDBC client drivers for SQL and stored procedure access. There is a server-side driver that acts as an SQL Gateway to interconnect with other databases. Caché has code generators to produce native Java objects from Caché-designed classes, as well as a native Java class library to allow inheritance from pure Java-side development. There are more Caché bindings to .NET and other languages. And there is still an ActiveX component for those carrying the baggage of legacy Windows apps.

Caché provides two interpreters for its developers: Caché ObjectScript and Caché BASIC. Their thinking there is for those new to the Caché development environment might startup with a more rapid and improved experience using a dialect that is more familiar than MUMPS. Caché extends these languages for writing server-side routines that can be invoked by the command-line, as a CGI from a web page, or as a Caché Server Page. My biggest belief that Caché is not more readily adopted is because of InterSystems Caché Studio. If they wanted to do their Caché development real justice, they would replace their IDE with a Caché plugin for the Eclipse project.

In summary, it should not be to anyone’s surprise that colossal HIS based on MUMPS technology has endured a span of decades in the modern business computing era, with no foreseeable end in sight, and despite ever-changing IT infrastructure. The exact same code and data that originated from a 1970s mainframe can still be re-used on today’s Linux-based web server farms that service the countless Firefox browsers. So my suggestion to Bryan and others like him looking for a career in computer programming: Caché, for the win!

One thought on “Caché: FTW!

Comments are closed.