And my point is that the language doesn't need to remain source compatible with the prior version to avoid breaking VistA. That being said, as large as it is, VistA is still only a computer program. The existing code will need to be updated and rewritten. I also believe that can and should be done incrementally, but the language does not need to be held hostage to the existing code.
--- James Gray <[EMAIL PROTECTED]> wrote: > I want to say that I agree very much with what you are saying here, > especially that the language needs to move forward. That said, I > think it > needs to not be changed in ways that will break VistA. I also think > we need > to accept that the language is going to move forward in a different > way than > having a resurected MDC. What needs to move forward also is both the > SAC > and the Kernel to allow ways to use the language extensions available > in GTM > and Cache. I wonder if the community is ideologically opposed to > moving the > language forward or just stuck on the idea that there is only one way > to > move it forward. > > Jim Gray > > ----- Original Message ----- > From: "Greg Woodhouse" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, August 23, 2005 9:42 AM > Subject: [Hardhats-members] MUMPS and VistA ( more M read questions) > > > >I actually didn't know that MUMPS_V1 was (now) open source. > Originally, > > I was looking for a version of MUMPS that I could run under Windows > > but, as I recall, the developer was adamant that it not be ported > to > > Windows, so it was of no real use to me. Since then, I've decided > to > > use OS X as my primary operating system, so that may not be an > issue. > > But as I said before, ther are other things I'm interested in doing > > right now. My opinion is that MUMPS is an underappreciated > language, > > and I believe that it is in the long term best interest of the > MUMPS > > community to move the language forward. I also believe it is > feasible > > to do so, but the community seems almost ideologically opposed to > this > > course. The argument is framed as one of "practicality" or of > "saving > > VistA", but I don't think marrying ourselves to the existing code > base > > without providing a way forward is saving VistA. At best, it's > getting > > a product out the door. > > > > --- Jim Self <[EMAIL PROTECTED]> wrote: > > > >> Greg Woodhouse wrote: > >> >--- Jim Self <[EMAIL PROTECTED]> wrote: > >> > > >> >> Greg Woodhouse wrote: > >> >> >Off hand, I don't know, but members of this list do seem to > have > >> a > >> >> >tendency to "plug" GT.M (presumably because it is open > source). > >> >> >Personally, I think we'd all benefit from a little more vendor > >> >> >neutrality. > >> >> > >> >> I am not a vendor and neither is GT.M. > >> > > >> >No, but Fidelity is. > >> > >> If you know my history, then you should know that I advocate Free > >> MUMPS, not vendors. You > >> do not buy a license for GT.M/Linux from a vendor. You download it > >> from Sourceforge or get > >> it from a friend. > >> > >> >Open source may be a > >> >good thing (and I think it is), but is it being touted because > it's > >> the > >> >"right" way to do things or because it's the cheapest? > >> > >> I don't know of any serious advocate of Open Source or Free > software > >> who doesn't primarily > >> believe that it is the right way (and perhaps ultimately the only > >> way) to develop and > >> promote open standards for computing and the knowledge that we > need > >> (widespread and deep) > >> to develop and maintain secure and reliable computing and > >> communications systems in the > >> long term. > >> > >> >> At the moment, GT.M is the only Free (Open Source) MUMPS > >> >> implementation that has been > >> >> taken seriously enough by VistA developers to make VistA work > on > >> it. > >> > > >> >Perhaps so. But reason may only be that it has become something > of a > >> >juggernaut -- people put their efforts into GT.M because that is > >> where > >> >other people are putting their efforts, > >> > >> MUMPS_V1 was freely available for a good while before GT.M was > >> released for Linux, but > >> unfortunately, MUMPS_V1 was only free, not Free (Open Source) > until > >> some time after > >> attention had shifted to GT.M. Before that I worked with it and > >> tested it repeatedly for > >> conformance to the MUMPS standards and talked it up on this list > and > >> elsewhere as a > >> serious effort at implementing standard MUMPS that was worthy of > >> serious attention. It > >> still is. > >> > >> --------------------------------------- > >> Jim Self > >> Systems Architect, Lead Developer > >> VMTH Computer Services, UC Davis > >> (http://www.vmth.ucdavis.edu/us/jaself) > >> > > > > > > > > === > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Design quality doesn't ensure success, but design failure can > ensure > > failure." > > > > --Kent Beck > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > 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 > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- 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
