Volume 4, number 4, September 1996, pages 44-45

Windills
The nice thing about standards is that there are so many to choose from

by Ed J.P.M. de Moel

I have heard this claim many times, and it certainly is a very true statement. However, how much of a choice do we really have when making a decision between multiple standards?

Looking at the events during the Apollo 13 flight, the engineers had a choice between square and round connectors on the carbon monoxide filters. Whether one saw the dramatized movie, or the documentary that represented the events in a more matter of fact manner, the impression that remains is probably the same: there is nothing "wrong" with square couplings, and there is nothing "wrong" with round ones, but whichever one you choose, if you don't make the same choice throughout, people are likely to be in for a very hard time.

A couple of years ago, Thomas Salander reminded us about the fire of 1904. Just because there was a difference in the diameters of the fire hoses of the various departments and cities that sent their fire fighters and equipment to Baltimore, most of that city burnt down. Once again, there was nothing "wrong" with the diameters of any of those hoses, but since they didn't fit together, the result was a disaster.

Do we see the same phenomenon in current day computer activities? Certainly.

Over the past 10 years, I have worked with both WordPerfectTM and MS WordTM (and a couple of other word processors). There is nothing "wrong" with any of these packages, but when you try to convert a document from one into the other, "most" of the lay out features will be retained, but all the hard work you put in getting things to look "real nice" will disappear, or even turn into a downright ugly result. Once again, it doesn't really matter which one you choose, but having chosen one, you'd better stick to it, or you'll have to re-do an awful lot of work.

Over the past 20 years, I have worked with at least a dozen different programs to edit program source code. Some are more "user friendly" than others, but whatever the features of your favorite editor, if it isn't available on the system where you're working today, you'll have to make do with whatever software is available there. Don't you hate it when you hit a "familiar" function key, and "today's program" does something quite unfamiliar (or even destructive)?

Here also, there is nothing "wrong" with the key selection that the programmer of either editor program made, but it sure is bothersome to have to adjust and learn the "other" selection.

Now, what am I getting at with all this?

Very often, people ask me: "Why do you M[UMPS] folks do things this way? Nowadays, everyone else does it that way."

The simple answer to that question is often: "Because, about 30 years ago, someone made that decision, and we don't want to upset all the users of the language by forcing them to review (and possibly rewrite) their code in order to change to the new method."

But, is that answer really always valid?

In the case of $TEST, 30 years ago, static state variables were popular; nowadays, it is much more popular to work from a modular model, and think of this value in a more "stacked" manner. Changing this feature of the language to "become modern" would indeed break something that many people feel we'd better stick to...

However, the urge to "be like the rest" is getting stronger and stronger every year, and I would not be surprised if, in the near future, there would be an addition to the language that would eventually make $TEST obsolete by addressing logical choice issues in a stacked and modular fashion.

In the case of "object orientation", there has been a lot of effort put into fitting practices that belong to the object oriented world into the framework of the existing M[UMPS] language. Having looked at the efforts of the people making these attempts, I think they do feel like they are trying to fit a square pipe into a round hole that is just a little too small (all this while they wished the pipe to be round and the hole to be square and large enough).

There have been suggestions to start work on M-2000, an "all new" language that looks similar to the familiar M[UMPS] language, but only propagates its strong points and relinquishes all the "baggage" that keeps us struggling to fit "modern" concepts into an "old" model.

An obvious advantage to this approach would be that existing code would not suffer from any developments in the "new" language, but an obvious disadvantage would be that an interface between the two languages would have to be developed as well. After all, however desirable the new features that this new language could introduce, who would want to go through the trouble of re-writing all existing code to meet the specifications of the new language?

Surely, in the past, translators were made available to facilitate such transitions, and tune-able translators are currently available. But since the existence of such translators has not proven to be much of a motivation to, say, replace all occurrences of $NEXT by $ORDER, and change the further code to reach to empty boundary values, rather than a value of -1, I doubt that there will be a great urge to use such translators to replace "traditional M[UMPS]" by M-2000 (or whatever new name we may come up with).

There have been suggestions to "ignore" the M[UMPS] models for a while, and build object oriented extensions based on what "everyone else" currently does, and then fit that solution into the M[UMPS] language.

Although the discussions that I currently see in this context are mostly about which segment of the computer population is the "everyone else" that we wish to follow, it seems that the various proponents of different directions are starting to find common ground.

All these efforts and approaches seem to be in the vein of the statement at the top of this column: we have to choose a standard, but which is the one that will work best at this moment, and that will continue to support us well into the next century?


Ed de Moel is past chairman of the MDC and works with Jacquard Systems Research. His experience includes developing software for research in medicine and physics. Over the past ten years, Ed's has mostly focused on the production of tools for data management and analysis, and tools for the support of day-to-day operation of medical systems. Ed can be reached by e-mail.