Greg:
This is really a useful discussion for the M and VistA Community because
it probe's the idea of "standard". At the 1989 MUG Meeting in Seattle we
had an extensive session on this. My work definition is
"standards"="common conventions" (of all types). There are specifications
practices, guides in the ASTM framework and like catgories in other
Standards Developer Organizations (SDOs). There are also sveral standards
related to the M Language, The langauge specification being just one.
Consider the idea of a "Standard Practice for Use of M in the System Life
Cycle" to coin a title for a relevant M standard. Such a documnet if
drafted and approved by the MDC could refer to all other information
systems standards and how they might applying in the various Processes and
Activities of diffferent MUMPS systems projects. It would not be
a Specification, which is the conclusion many jump to when you speak
"standard". The M Community needs to be conversant with the full voluntray
consensus standards process in both the US and the world, as well as how
to optimally use standards. It requires thought, produces mastery and
ability to get things done in an effective fashion. The M Community is
thoughtful, and skilled and can develop this posture. That will ensure M
not being put in any "Procustean Beds" such as "MUMPS is Old". Real effort
should be channeled into the World VistA effort to revitalize the MDC and
also the dialog form that MUG/MTA provided for the M Community; such
revitalization will benefit a lot of folks.
On Tue, 28 Jun 2005, Greg Woodhouse wrote:
I agree with you that there's a real irony here in that "MUMPS is old"
is rhetoric is becoming more common at the same time that rqapid
prototyping is coming (back) into vogue.
I am really of two minds when it comes to the relationship between life
cycle models and standards bodies. The main issue is whether a life
cycle model should be tied to a language by being incorporated into its
defining documents (or closely associated documents). A second, perhaps
more nebulous, issue is the question of just what it is that
constitutes a language definition. Certainly, syntax and semantics
(narrowly construed) are part of a language definition, but what about
pragmatics? I would not say that scholars engaged in the study of
English pragmatics are not "doing linguistics".
Even so, if the pragmatics of MUMPS does include such concepts as rapid
prototyping, is this something that needs to be *specified* or even
*described* as part of the language standard? I'm not at all sure that
it does. Standards may exist for life cycle models (a problematic
notion in my opinion, but one I don't necessarily consider improper or
not to be useful) then it may well be reasonable to ask how that
standard (or other document) *applies* to a specific language. To me,
this seems the proper context for discussing life cycle models, and is
conceptually rather different from trying to incorporate a life cycle
model into a language definition (unless, of course, this is something
the language was specifically meant to address).
--- "A. Forrey" <[EMAIL PROTECTED]> wrote:
Yes, I was refrring to the XP LCM which has been under discussion.
The
concept of Rapid Protoyping arose in the same time frame (late 1960s)
as M
but the ASTM E-1340 arose in the mid 1980s after DHCP and the first
X11.1
MUMPS std were already out but it arose specifically for guiding
healthcare applications as a resulkt of the early VA experience. It
is
tied to the IEEE/JTC1 SC7 IEEE-1074, IS 12207 etc general standards
but
clealry depicts how the same best recommended practices can be
effectively
harnessed to underpin a technology like M. The MDC's task is to
describe
how to adhere to all the needed practices without being impeding the
advantages of the M environment. Quickly documnting these best
recommended
practices consistent with the general posture will explicitly
strengthen
the use of M environment and be in agreement with the principles that
were
part of the CMU criticisms of the DVA's approach to VistA evolution.
Many,
if not most, of the VA working developers/maintainers - if not some
in the
administrative track - had already utilized these principles. Dan
Gray and
others had participated with IEEE-CS in the 1074 standard that led to
the
IEEE/JTC1 SC7 series and carried these principles into the work of
the MDC
into 1999 as well as appropriately incorporated the ideas into
practices
within the VA. The task now is to ensure that the M/VistA community
clearly articulates the appropriate application of these principles
to not
only the VistA/VA effort but also to the numerous other health
informatics
Suppliers in the market that use M. Such visible use of, and
reference to,
these principles will put the lie to those who tout the "MUMPS is
Old" and
showe that they arent paying attention to whats going on. It will
just be
one small step in appropriate applying M to all problem areas that
can
benefit. It will, however take all of us to keep reminding the world
of
key facts.
On Tue, 28 Jun 2005, Greg Woodhouse wrote:
By "that" do you mean XP (which is not really a life cycle model)?
I don't know that I've ever heard it claimed that rapid prototyping
*originated* with M, but I certainly agree that M is a language
well
suited to rapid prototyping, and that it was one of the first
languages
of this type.
--- "A. Forrey" <[EMAIL PROTECTED]> wrote:
Thats one Life Cycle Model useful for certain problems. Another
which
is
much more prevalent in the M Community is Rapid Prototyping which
almost
originated with the language; an updated ASTM E-1340, just
completed,
describes this LCM. Its best recommended practices related to M
will
be
one task for the MDC but should be complex or burdensome.
On Mon, 27 Jun 2005, Kevin Toppenberg wrote:
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Design quality doesn't ensure success, but design failure can
ensure failure."
--Kent Beck
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Design quality doesn't ensure success, but design failure can ensure failure."
--Kent Beck
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
