The MUMPS Community: A Commodore Analogy

Eric S. Raymond’s Jargon File defines Amiga Persecution Complex as follows:

The disorder suffered by a particularly egregious variety of bigot, those who believe that the marginality of their preferred machine is the result of some kind of industry-wide conspiracy (for without a conspiracy of some kind, the eminent superiority of their beloved shining jewel of a platform would obviously win over all, market pressures be damned!) Those afflicted are prone to engaging in flame wars and calling for boycotts and mailbombings. Amiga Persecution Complex is by no means limited to Amiga users; NeXT, NeWS, OS/2, Macintosh, LISP, and GNU users are also common victims. Linux users used to display symptoms very frequently before Linux started winning; some still do.

The MUMPS community too often falls victim to this syndrome, frequently lamenting its small size. “We must train up the next generation of…” begins all too many sentences here. While there’s no harm in seeking out and training new MUMPSters, I don’t believe it is strictly necessary for us to win in the numbers game. We also too frequently look to large government agencies like the VA to bring about our wishes instead of bringing them about ourselves: a feat I believe to be well within our reach.

For illustration, let’s look at the saga of the Amiga personal computer.

The Amiga was developed in the early 1980s by Hi-Toro, which would later become Amiga Corporation, in turn acquired by Commodore Business Machines. Vastly ahead of its time, the  1985 Amiga included a Motorola 68000 processor, dedicated custom ICs for multi-channel waveform sound, full-color graphics, sprite-based animation, fast memory transfers, the unique feature of having all system bus timings evenly divisible by the clock frequency of NTSC video, and a GUI-based virtual memory operating system with preemptive multitasking. The system improved steadily through the 1980s and early 1990s, until a series of business and technological missteps led to the 1994 bankruptcy and liquidation of Commodore. The Amiga technology was purchased by German PC retailer ESCOM AG, which continued to manufacture slightly facelifted versions of the last Amiga systems offered by Commodore, until ESCOM AG met its own demise in 1996. Eventually, the Amiga patent portfolio was snapped up by PC manufacturer Gateway 2000. Many vague promises were made to the Amiga community about a new generation of Amiga hardware and software, but none were ever delivered, and ultimately, two Gateway 2000 employees, Bill McEwen and Fleecy Moss, bought the Amiga patents from Gateway 2000, forming Amiga Inc.

The small Amiga Inc. began once again manufacturing the late Amiga models, and licensed Haage & Partner to develop and release AmigaOS 3.5 and 3.9, the first AmigaOS updates since the Commodore bankruptcy. Keep in mind that both Amiga Inc. and Haage & Partner are tiny, private companies, and mere blips compared to Commodore and Gateway. Amiga Inc. also licensed the Amiga branding for the AmigaOne line of PowerPC-based Amiga systems, production of which continues today. Amiga Inc. licensee Hyperion Inc., a tiny video game porting firm, has released AmigaOS 4.0 and 4.1, bringing substantial improvements to the platform. The Amiga, long since declared dead by the mainstream technology press, now has:

  • Modern hardware systems with fast CPUs and modern expansion busses based on original board designs–considered a substantial accomplishment for the small companies that produce them
  • A modern and blisteringly fast operating system (AmigaOS 4.1) with modern web browsers and a large number of native applications

All of this was accomplished by a very small and dedicated community with a minimum of resources, one which thumbed its nose at the slow-moving giant (Gateway 2000). I may be crucified for saying this, but either of these major components (hardware platform and operating system) are significantly more complex, more difficult, and more expensive to implement than any EHR. Amiga systems have been in near-constant production since 1985, weathering multiple sales and bankruptcies, and continue to serve their small and faithful community well.

IBM OS/2 is another such example. I will not go into great detail, but to say that IBM abandoned the technology, only to have it licensed and improved upon by a tiny outside ISV (Serenity Systems Inc.) under the name eComStation, and the operating system–much like the earlier mentioned Amiga platform–continues to be improved to serve its faithful user community to this day.

MUMPS and VistA are very similar: technologies well-loved by their fiercely dedicated communities, declared dead by the mainstream press, largely stagnated at the hands of their large corporate and governmental implementers (who either have no business case to innovate in the space, or have an active goal of replacing the technology simply because it’s not new). The community built up around the technology should try to be a Serenity Systems Inc., a Bill McEwen, a Fleecy Moss, rather than waiting on our own Gateway 2000 (the VA) to deliver our favored technology’s salvation. If tiny companies can acquire an expensive, closed-source, proprietary platform, improve upon it, and handle the logistics of manufacturing a physical product, this community has more than enough manpower, talent, and resources to do the same thing for MUMPS and VistA. The difficulty is that our community has shown an alarming propensity towards talking about solutions and creating grand visions while seeming to hope that the code required to make them happen will simply pop out of the ground (or that the VA will open the floodgates and all will be as it was in VistA’s halcyon days–a pretty plot for a fairy tale, but highly unlikely given the entrenched dynamics of Washington politics).

Lest I come across as a Debbie Downer, there are pockets of this community that give me encouragement every day: VistA is about to have long-awaited modern user interfaces thanks to the highly commendable efforts of Sidney Tarason at Astute Semantics, which have a “wow factor” I haven’t ever before seen in this space. MUMPS and VistA users now have two open-source choices for building web apps that access MUMPS and VistA data: Rob Tweed of M/Gateway Developments has released the elegant, modern, and fast EWD.js, exposing MUMPS and VistA within the highly popular Node.js environment, while I personally have released CFMumps, which provides a cohesive high-level API for developing MUMPS and VistA web apps in ColdFusion and Railo–both environments that sit firmly in the J2EE model, while exposing a highly-simplified view thereof. Both are great candidates for VistA and MUMPS exposure and modernization in the web space, but we should not fall into the thinking that either is an acceptable substitute for evolving the core technologies of VistA, which means MUMPS code, and improving MUMPS code should involve evolving the MUMPS language. This has to be a community process, as the vendors have no reason to care, and the VA is unlikely to start caring.

If the entire community can draw from the spirit of Astute Semantics, M/Gateway Developments, and Coherent Logic Development, and get its nose out of politics and into code, much can be accomplished very quickly.

Let’s get coding!

Java: Why no true constants?

I find it odd that Java–a language intended to facilitate and encourage the development of elegant programs–never finalized (no pun intended) a way of expressing true constants. The closest you can get is “final” variables, that can only be initialized once, i.e.:

private static final int MSG_ERROR = 1;

But, they fall short, as they can’t be used in place of a constant expression, such as a “case” label in a “switch” construct; i.e., this will fail:

switch(msgLevel) {
case this.MSG_ERROR:
// do something

because javac doesn’t consider a “final” variable to be a constant expression. You’d have to do:

switch(msgLevel) {
case 1:
// do something

Which renders the case label’s purpose less than intuitive. Sure, we could use a comment after each case label, but that’s rather hack-ish, in my opinion: one of the most widely accepted best practices for writing clear code is to avoid the use of “magic” numbers (numeric constants that aren’t self-explanatory). In the case of Java, the language itself forces us–in certain cases–to use them. For a statically-typed language–even one with built-in garbage collection and automatic memory management–this seems a rather shameful trade-off. Apparently, Java reserved a keyword for constants early on, but it was shelved somewhere around 2005.

Why, Java? Why?