And that is what would happen if the order of operations were changed unless
there were a new command that had a different order of operations.
Jim
----- Original Message -----
From: "Gregory Woodhouse" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, August 21, 2005 10:10 PM
Subject: Re: [Hardhats-members] MUMPS features
I can assure you that the SACC would like nothing more than to avoid
placing unnecessary burdens on the user/programmer. The issue here is
whether relaxing limits like the restriction on string lengths would break
existing applications.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Design quality doesn't ensure success, but design failure can ensure
failure."
--Kent Beck
On Aug 18, 2005, at 4:34 PM, James Gray wrote:
I do not think the choices are either or. I think Mumps must continue
to exist to support VistA or it will wither. That does not mean it
cannot evolve. I think it is evolving. We just aren't paying
attention. Cache is not the same as Intersystems Mumps 10 years ago. I
do not know about GTM, but I bet it is not the same. It is the VA SAC
that has not evolved much at all. The hardhats community would like for
all of the breeds of Mumps to evolve in lockstep via an MDC. I fear
that is a lost cause. I think we need to learn that the language is
evolving in a different way now. I personally think it is the SAC that
needs to evolve now.
Jim Gray
----- Original Message ----- From: "Greg Woodhouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 18, 2005 4:47 PM
Subject: RE: [Hardhats-members] MUMPS features
When you get right down to it, it's a matter of perspective. Languages
evolve, and not always in a backwardly compatible way. If the "prime
directive" is to be able to run some existing program (such as VistA)
without modification, then you're sort of stuck. But is MUMPS a
language that exists simply to run that one application? It may be just
that, but if this is so, then we can hardly wonder why there isn't more
interest in MUMPS as a language. As much as we may protest that the
design choices made in MUMPS were reasonable, the language remains
frozen in time, and increasingly unlikely to be adopted in new work.
That's a shame, too, because as I've tried to argue, there is a lot to
recommend it as a language. Obviously, there was a time when the
community thought developing a new version of the language was the
right thing to do, but that idea has been abandoned. What message does
this send to the larger development community aa to the long term
viability of MUMPS as a language? Realistically, it has become little
more than the abstract machine upon which VistA runs.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
