I guess I was thinking along the lines of how different could they become. There is much talk about enhancements to the language, but it seems to me that enhancements the core packages could support much of what would be desired.
Even when there were several significant vendors, language enhancements took many forms. System level enhancements would likely still differ between implementations. The Kernel should be used to mask these differences. Are World VistA and VOE bound to the FOIA Kernel? How would such enhancements be implemented? Maybe as a separate package, sort of a Kernel add on? Who manages such a thing for WV? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Schlehuber Sent: Wednesday, August 24, 2005 6:58 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Re: MUMPS v2? (and its implications for VistA) The only two changes to Kernel's DD are a new code (E for EHR) in the set of codes in the AGENCY CODE field .02 in the AGENCY file 4.11 and the same code added to the AGENCY CODE field 9 in the KERNEL SYSTEM PARAMETERS file 8989.3. And hashing algorithms are replaced for the stub routines XUSHSH and XUSHSHP that are redacted in the FOIA version of the routines. Of course, there is a fair amount of "localization" and initial setup that must always be done. VOE has improved on those steps just a bit. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Monger Sent: Tuesday, August 23, 2005 9:01 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Re: MUMPS v2? (and its implications for VistA) Not sure that a MUMPS V2 is viable, but I think much could be implemented by Kernel to enhance the functionality. To what extent will Kernel differ between World VistA distributions and FOIA VistA? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Tuesday, August 23, 2005 12:57 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Re: MUMPS v2? (and its implications for VistA) As an outsider, I would say that not breaking old code means that the new M system can load up and run vistA code without having to wrap it etc. No one seems to like change (just look to our discussion of "F" vs. "FOR" vs "for" etc.) So creating a new language by committee might be the kiss of death. Sometimes there just needs to be a smart leader that puts something out there, and then see if it catches on. It seems like there is such a leader behind perl or phython. I read an interview with him once on slashdot, but his name escapes me. Kevin On 8/23/05, Greg Woodhouse <[EMAIL PROTECTED]> wrote: > Unlike Jim Self, I've never had occasion to review the source code of > GT.M but I do not doubt that it is very well written. Compiling a > dynamic language like MUMPS does, of course, does pose special > challenges due to its dynamic nature. If I can invoke a routine > indirectly (by name) at run-time what are my options? Two obvious > alternatives that suggest themselves are compiling to an intermediate > representation (like Parrot from the Perl 6 project) or to rely on some > combination of thunking and just in time compilation. Nevertheless, it > should be possible to compile and run existing code. XECUTE statements, > of course, are used to executed MUMPS source that is specified at > run-time and so isn't really amenable to the same shortcuts as > indirection. > > That being said, it is not obvious to me that there is any technical > reason that existing compiled code could not be linked with VistA > components written in a newer version of the language, and hence the > requirement to not break existing code does not imply that the language > has to be frozen in time. Thus, it seems to me that the backward > compatibility argument is really a red herring, and the truth is that > there is little interest in developing a new version of the language. > That's fine, of course, but *I* am not particularly interested in > porting MUMPS to new platforms if there is little interest in updating > the language. > > > === > 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 > Hardhats-members@lists.sourceforge.net > 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 Hardhats-members@lists.sourceforge.net 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 Hardhats-members@lists.sourceforge.net 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 Hardhats-members@lists.sourceforge.net 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
