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