ills
In previous columns, I have emphasized the point that the important thing about standards is not so much what features these standards provide, but that, instead, the benefit lies in the agreement between various groups of users of the standard that a certain common way of doing business is a safe and profitable basis to build on.
While I don't mean to contradict this point, there is a danger in adhering to this principle too strictly: when one is restricted to only those features that are described in a certain document, there will be no room to take advantage of new developments and new products that are created outside of the group of users of a standard.
Having carefully set up a process for the development of standards that ensures that all parties who have an interest in the content of the standards documents also have a say in what that content is going to be, we are now in the situation that the minimum time between the publication of subsequent versions of standards has grown to the order of magnitude of three to six years. In the "real" world around us, software products are created, and become obsolete, in a period of less than two years. This disparity makes it difficult to predict what the needs of the user-community will be by the time a next edition of a standard is to be published.
To illustrate this issue, we only have to look back on our own history. Six years ago, it was imperative for any provider of database oriented software to make certain guarantees about "transaction processing" capabilities. The M[UMPS] vendors put a great amount of effort in providing these capabilities in their products, and in supporting the MUMPS Development Committee in providing language for the standards documents that would correspond to their enhancements. Today, transaction processing is as important as ever, but everyone is also aware of the issues around network connections, delays, mirrored or replicated information, etcetera. Those installations that indeed need the capabilities that were "required for everyone" five years ago, have found a way to overcome the hurdles that are between the programming language standard and the physical world, and most other users of the language hardly care about the issue anymore.
Even shorter ago, there was a great perceived need to bridge the gap between the four major methods of offering windows-oriented interaction: MacintoshTM, X-WindowTM, Microsoft Windows 3.1TM and Character-cell based cursor addressing. Everyone will probably have their own reasons for thinking that three of those four candidates were not really a safe enough basis to build on, and which three of those four that were will be a different assessment from person to person... but, all four still exist, be it that some have evolved more than others. Again, the M[UMPS] vendors put a great amount of effort into providing a set of extensions that is now known as the MUMPS Windowing Application Programmers' Interface (MWAPI). Now that the standard document for these language extensions has been approved, the world has been overrun by Windows 95TM and Windows NTTM, and the perceived need for standardization from the point of view of a programming language has dwindled considerably.
Only a couple of years ago, there appeared to be a great need to include POSIX compliance in the language standard. It is not at all clear whether the need that was perceived at that time is still present...
We are now at the point of making decisions about the final content of the next edition of the various M[UMPS] related standards. There appears to be a great demand to add "object oriented" extensions to the language. Frequent readers of this journal have seen a plethora of articles providing insight into either a specific need to add object oriented extensions, or explanations about specific ways of implementing object orientation in a M[UMPS] environment.
But... the "real" world around us has evolved as well. Currently, there are a number of approaches to dealing with object orientation. Many users of M[UMPS] implementations already have the opportunity to try out the extensions that their implementors have included in their products. For those implementations that run on IntelTM hardware, it is not surprising that the implemented approaches are compatible with Microsoft's trademarked OLE (Object Link Embedding) and COM (Component Object Model) principles.
Aside from OLE and COM, there is also CORBA (Common Object Request Broker Architecture), which appears to be much closer to the level of theoretical abstraction that is desirable for inclusion in a standards document, but also appears to be much further away from the general level of acceptance that makes it a candidate for use as a standard.
And, of course, there is OMEGA, the current MDC project to build from scratch a new M[UMPS] like language, based on object oriented principles.
What to do? Embrace a model that appears to be more "theoretically sound", or embrace a model that appears to demonstrate a more widespread use? Will the usage that appears to be prevalent at this moment still be the same by the time that a next standards document is ready for print?
I think that the time has come for the users of the standard to communicate their business needs to their vendors, so that they may implement products that support these needs. Should the implementors end up providing dissimilar implementations, then it becomes time to lobby the standards makers and give them arguments why one solution should become the standard rather than one of the other candidates.
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.