Removing vista-officeehr-forum from the list, since this is a technical discussion and that list is mostly those interested in implementing VistA Office EHR. Other comments below.
-- Bhaskar Gregory Woodhouse wrote: > > On Jun 13, 2006, at 3:11 PM, K.S. Bhaskar wrote: > >> ...features defined in the standard but not supported by one or >> >> another MUMPS implementation (e.g., ACID transactions),... >> > > This goes beyond the scope of what I initially had in mind, but it > seems to me that a major advantage of high level languages (like > MUMPS) is that compilers can generate code for a target platform. If > different dialects of MUMPS are compilable, then they can still be > portable. But the infrastructure needed to support ACID transactions > goes well beyond this, and so (for good or ill) MUMPS seems positioned > somewhere between a language and a DBMS, making portability a much > more sticky problem. [KSB] I see your argument, but I see things a little differently. ACID transactions are critical to implementing robust applications, and there needs to be a way to bracket a set of database accesses & database updates and designate those as requiring ACID properties. MUMPS is not positioned between a language and a database - MUMPS includes both a language and a database, and is an ideal location for defining ACID semantics. Things get sticky when defining ACID properties across databases (e.g., for two phase commit), but they get sticky even in the non-MUMPS world (which is why I am not aware of any high end tranaction processing application that routinely uses two phase commit). I agree that in general, differences between M dialects can be occulted by a compiler encapsulates MUMPS. Indeed, in Profile, our banking application, we have a lightweight, typed, object oriented scripting language with a framework for creating financial products. That is what application logic is written in, and under the covers, compiled to GT.M. In much the same way, many Java implementations use a virtual machine that the typical Java application programmer never sees. _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
