ANYTHING but M++! Actually, I had in mind tagging the object code as old (or version 1, which sounds much better).
--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > I'm not opposed to moving the language forward. > I think it could be done in a way that would identify the new code as > new, and use different syntax. > > Such as put "SYNTAX NEW" or something at the beginning of the source > code. > > And we can call the language M++ :-) > > Kevin > > > On 8/23/05, Greg Woodhouse <[EMAIL PROTECTED]> wrote: > > 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
