4: 1990-1995 (MUMPS 1990). As MUMPS 1984 and VISTA (DHCP as it was known then) succeeded and led to increasingly complex software, it created its own problems, following the cosmic principle that success breeds failure. First, angry vendors who felt MUMPS's success robbed them of potential profit launched increasingly transparent attacks on MUMPS and MUMPS-based systems, leading to an interesting and developing new vein of insecurity and overcompensation. Second, the increasingly successful MUMPS systems grew complex enough that a new generation of execution- and variable-scope-management tools was needed. Fourth-generation MUMPS addressed both problems. The results showed in both the code and the new Mumpsters from this generation.
The New command, parameter passing, and functions (extrinsic calls and argumented Quit) introduced outstanding new power for controlling the scope of variables. Since variables are the greatest common source of spaghetti logic in MUMPS, these improvements were much needed, much used, and began a dramatic change in the look and feel of MUMPS code that is still playing out, since some packages introduced these new features more quickly and thoroughly than others.
Likewise, argumentless Do did the same for the scope of execution by (1) breaking free of the line-oriented length limitations of For, If, and Else that used to cause us to add named subroutines for no better reason than to extend the amount of logic within their scope, and (2) creating anonymous subroutines whenever we wanted to, for example to create variable-scoping boundaries for the New command to work with. Stacking $Test within do-blocks was crucial to making the former work.
Getting control of these two kinds of scope - variables and execution - extended our ability to reduce unnecessary complications (like labels we didn't need) and to increase needed system complexity (like more sophisticated package interactions). This was the standard that made MUMPS able to handle the open-ended development needed for enterprise-level systems.
This fourth generation also included some nice syntactic sugar - argumentless For got rid of the need for throw-away loop variables, Set $Extract simplified our handling of fixed-length fields, merge simplified our ability to move whole trees of data about, $Query made traversing trees easier, and $Get helped get rid of some ugly $Select/$Data constructs for handling potentially undefined variables - even aside from the usual collection of minor extensions and corrections. Routines and symbol-table sizes were only raised another thousand characters, but that still felt like plenty considering all the ways this standard gave us to reduce the size of our code by using the new, more concise language constructs. Likewise, the maximum variable-name length was doubled again to one hundred twenty-seven characters, to give us more room to name our increasingly complex data structures.
This was also the era in which we extended our standardization from the MDC and ANSI to include FIPS and ISO, making MUMPS a very standardized language indeed with an overtly international audience.
When experienced Mumpsters think about or talk about old MUMPS versus new MUMPS, we almost all agree that MUMPS 1990 is the dividing line. This was new MUMPS (with the New command no less), even though everything added to it is a refinement of what came before. Like MUMPS 1984, we almost all agree it was an almost entirely successful extension of the language - addressing the biggest problems and doing it almost perfectly.
Almost.
Because of the pressures the MUMPS community was under from hostile non-MUMPS companies, at the same time MUMPS was becoming an overtly modern, sophisticated, and international language, Mumpsters themselves were developing a defensiveness about their software they hadn't shown before. They became concerned not just about being effective but also about appearing effective. And modern. And being accepted by the larger computer-software community. This led to some problems that have plagued us since.
First, with modernism on their brain, Mumpsters decided to modernize the name of their language in the hope of making it more acceptable and marketable in the larger world. In hindsight, this was a naive mistake. The folks attacking MUMPS weren't doing so because of its name - that was just a cheap shot - but because they were either competitors trying to destroy support for MUMPS software so they could replace it with their own, or they were programmers proud of and committed to other programming languages who liked taking potshots at anything different than what they knew. Changing the name could do nothing to stop either kind of attack; the first group needed us to cease to exist, the second needed us to be what they already knew and preferred, in other words, to blend in and conform with them. In neither case could we remain Mumpsters or our language MUMPS, regardless of the name. This is more apparent twenty years later than it was at the time, which is why the community thought it would be a good idea to rename the language from MUMPS to M; MUMPS 1990 introduced M as an alternate name for MUMPS, with plans to swap the two names in the next standard, which it did.
It's important to note the cultural sea change in this capitulation. Not only were Mumpsters trying to change the name of their language, rather than choosing an original name that conveyed medical informatics in any way they opted for the most anonymous name they could think of - and in clear imitation of C, aping the mainstream in the hope of being accepted by them. It didn't work - it could never have worked - and the important thing about it is not its success or failure as a strategy but the deep and novel insecurity it revealed.
Second, also with modernism on their mind, the MUMPS community opted to begin phasing out the $Next function. It was made inadequate by the introduction of string subscripts in MUMPS 1984, since $Next's start and end values couldn't be changed without breaking existing software, and so couldn't be extended to handle string subscripts. That's why MUMPS 1984 introduced the $Order function, which was defined with start and end values to cover all conceivable subscripts now or in the future. That raised the problem of what to do with the $Next function. There were only two options: (1) to redefine $Next so that it made sense within the new subscripts, even though it had to remain as limited as ever, or (2) to remove $Next. The former would have allowed existing software to continue to work, but it would have left the old function as a historical appendage. The latter would make the language look ahistorical and "clean" - "modern" - but it would break all the existing MUMPS software that used $Next. MUMPS software is designed to develop over very long periods of time, so backward compatibility has always been a crucial guiding principle. With MUMPS 1990, the MUMPS community announced its intention to phase out $Next and required Mumpsters everywhere to rewrite all their $Next code to replace it with $Order. This was a very non-Mumpsy thing to do, but consistent with the name change it signaled an emerging insecurity so deep that they were willing to cause problems in order to improve their appearance.
Third, and in hindsight somewhat astonishingly, this MUMPS standard was not supported by a new Standard MUMPS Programmers' Reference Manual, nor a new Computer Programming in Standard MUMPS, nor a new MUMPS Primer, and the state-transition diagrams were removed from the standard rather than being updated. This was a third break with the past, and in some ways the worst of all. Without the MUMPS Primer and Computer Programming in MUMPS, the standard teaching material needed to train a new generation of Mumpsters was missing; we didn't notice at the time in part because there were excellent MUMPS training vendors at work in the community, but now the gap has become apparent and painful. Likewise, without the Programmers' Reference Manual the community lacks a fuller explication of what the standard means; the standard itself is extremely terse, so programmers need the fuller elaboration of its significance to fully master the new techniques. This is the first MUMPS standard that was never fully mastered by a surprising number of Mumpsters, many of whom still don't fully grasp how the New command or call-by-reference works, for example.
Since ANSI and ISO feel very proprietary about the text of the MUMPS standard, the Reference Manual is the only complete explanation of the MUMPS standard the MUMPS community itself owns. Leaving it out of date has put the MUMPS community in an awkward position, since now we don't have a ready-to-publish explanation of MUMPS that we have a right to publish ourselves.
The MUMPS Books project has made these problems so clear that I'm astonished we didn't notice at the time. Why didn't we update these three books again, as we did when we created the 1984 standard? Why only the standard and the pocket guide? Couldn't we see what the consequences would be? I don't know the answers to these questions - I would love to hear whether the principal players at the time know the answers - so I'm going to speculate based on what was happening at the time, and this is my fourth issue with MUMPS 1990.
Fourth, this was the first MUMPS standard not designed to be self-sufficient, to stand on its own even if no further standards came along. With the name change and the phase-out of $Next, MUMPS 1990 needed the standard that would follow it to finish what it started. We had become focused so much on the process of improving MUMPS rather than a specific result, that we were willing to release a standard that was not 100% stable, that depended on the future to complete what it started. Further, we had become so focused on being accepted more broadly and on the appearance of modernism that we were willing to break our commitment to backward compatibility and even try to change our identity.
None of that's speculative; it's right there in black and white in the text of the standard itself.
Here's the speculative part. I think the reason we didn't update the three works that were supposed to accompany the standard is that we either forgot or dismissed the issue, that we either didn't notice the omission or forgot its importance, that we'd lost track of the fundamentals because we were so focused on and proud of the standard itself. When the 1990 standard was approved by ANSI, we were already working on getting it approved by NIST and ISO and more to the point we were working on what would become the 1995 standard, which even in 1990 we knew would be full of exciting MUMPS extensions. We were too busy preparing for the next generation of MUMPS to finish the current one. I suspect we as a community decided either consciously or unconsciously to put off updating the supporting works until the next standard - not realizing that we were going to make the same decision after the 1995 standard was completed.
As we'll discuss in the next generation, the release of the 1995 standard was accompanied by an almost delirious excitement, pride, and sense of progress. I don't think that came out of nowhere.
It's worth noting that the 1995 standard had the same kinds of strengths and weaknesses this one did - revolutionary new extensions, problems with backward compatibility, and a failure to update the three supporting books - only more pronounced. The 1990 Standard MUMPS Pocket Guide was at least complete; the 1995 Standard M Pocket Guide, which I wrote, was published before we could finish describing the 1995 language, and the other 1995 standards never got any supporting material at all. We started work on the 1995 Reference Manual, but we were spread too thin, working too hard on putting the new standard to work and on creating the next one, to have the time to really focus on it, so it never got beyond an outline.
Further, the 1995 standard contained errors in the standard itself. The $Reference extension didn't make it into the 1995 standard, even though it was meant to, and even though part of the standard actually names the missing system variable. As we discovered later, the error-processing extensions were full of ambiguities that later MUMPS extensions had to clean up. And we're currently exploring the transaction-processing extensions looking for similar but subtler problems.
My fourth point, then, is that MUMPS 1990's revolutionary qualities came with and perhaps were even symptomatic of and driven by a growing insecurity among Mumpsters that led to a change in focus toward progress and modernization that led to sacrifices being made in some of MUMPS's fundamentals. In our race to get to the future, we'd lost track of the importance of creating a stable, sustainable present.
Mumpsters from this era tend to embody that enthusiasm, insecurity, and confusion. They're modernists, focused on improving the old code and finding ways to demonstrate their modernity and high-tech credentials. They're the first generation of Mumpsters who really feel shame about MUMPS, specifically about "old" MUMPS, but they're also proud of "new" MUMPS. They write code using the new scoping features, which lets them create innovative and complex architectures, and they think a lot about how to "modernize" MUMPS and VISTA. Though they're as excited as any other generation about the chance to write a new package from scratch, they don't often get that opportunity because so much architecture has already been created in the systems they work on. Refactoring is a big attraction for these Mumpsters, because with so few new packages to write this is how they can master the software they work with. They're change agents who work to revolutionize what already exists.
I know this because when the 1990 standard came out I and most of my peers fully embraced this culture and internalized it. It was the logical progression of the work I'd already done refactoring Task Manager, and it offered me the tools I needed to take that work to the next level. I and most other Mumpsters eagerly embraced the many good things about this standard, even as many of us also unfortunately unconsciously absorbed the insecurity and focus on modernism and popular acceptance. The balance on this standard was easily, overwhelmingly on the good side.
_________________ Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net "The hidden harmony is best." - Heraclitus of Ephesus
|