I am of two minds on this one. Creating a whole new language (and implementations for it) is a big task, not one to be undetaken lightly. Ideally, I'd like to see an approach that would support incremental updates to VistA, but that's easier said than done, for reasons I've discussed on another thread. I have also argued that code really does have a "shelf life" and that we really do need to start thinking (in earnest) about modernizing VistA.
But there is a reason why there are so many languages out there, and it's not just marketing. No one language is ideal for every purpose. Forget that: no one has ever succeeded in designing a language without significant shortcomings. I was intitially very enthusiastic about Java (and I still like it very much), but developing Swing applications in Java is enough to convince me that something is really missing. I'm also not convinced that the object oriented paradigm is the answer to all our problems. I stopped by Barnes and Noble yesterday, and there was a big section labeled "Software Engineering" where all the books were about UML, object oriented technology, patterns and the like. The time may very well be right for introducing a new language, but certainly there are many well-designed and mature languages out there that could suit our needs very well. --- Greg Kreis <[EMAIL PROTECTED]> wrote: > If we tried to fix the main concerns, it wouldn't be backward > compatible > with VistA. Also, why make a radical overhaul of MUMPS when there > are > many other languages already supporting objects, etc. that are well > established and have opensource versions that are well tested. (I am > > not comparing them to GT.M, just making the point that they are > mature > and ready to use). I know some feel very differently about MUMPS and > what should be done. I've read that the trend in opensource is in > the > area of applications, not the lower layers such as languages and > databases. Those are well developed areas and the battles already > won, > right? > > Nancy Anthracite wrote: > > >We have got to get moving again on this plan for a replacement for > the MUMPS > >development committee. Greg, why don't you and Greg Woodhouse start > working > >on that since Greg is bored. ;-) > > > >On Tuesday 06 September 2005 12:21 pm, Greg Kreis wrote: > >Hindsight is 20/20, but I sure wish that someone had seen the wisdom > of > >creating a new class of array storage that had the following > >characteristics. > > > > 1. Disk-based so it didn't impact partition memory > > 2. Temporary (automatically was killed when the process > terminated) > > 3. Supported nodes with WORM features (not required for all nodes > of > >the storage) > > 4. Supported the idea of private and public branches of nodes > > > >The SSVN concept seems like it would be a great way to implement the > >above. Maybe there is no wisdom in what I described.... but either > way, > >it is too late for VistA. The best we can do is instill consistent > >programming practices to maintain backward compatibility, right? > > > >Greg Woodhouse wrote: > > > > > >>I guess the subject line says it all. Can anyone make a case for > >>supporting dynamic scoping rules? > >> > >>I realize that my previous post on this topic was a little unclear > >>about the nature of dynamic vs. static scoping. Variables withing a > >>nested block can hide variables by the same name in an enclosing > block > >>under static scoping rules, too. A simplke example of something > that > >>does require dynamic scoping is > >> > >> > >>S D=4 > >>W !,$$INC(1) > >>Q > >>; > >>INC(PI) ; > >>Q PI+D > >> > >>Under static scoping rules, this code wouldn't even compile, > because > >>whether or D is within scope in the body of INC depens on whether > or > >>not it was bound when the call was made. > >> > >> > >>=== > >>Gregory Woodhouse <[EMAIL PROTECTED]> > >> > >> > >> > >>"Perfection is achieved, not when there is nothing more > >>to add, but when there is nothing left to take away." > >>-- Antoine de Saint-Exupery > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>------------------------------------------------------- > >>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 > >> > >> > > > > > > > > -- > Greg Kreis http://www.PioneerDataSys.com > > "You are today where your thoughts have brought you, you will > be tomorrow where your thoughts take you." (James Lane Allen) > > === Gregory Woodhouse <[EMAIL PROTECTED]> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery ------------------------------------------------------- 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
