Greg, have you ever read anything you haven't had something negative to say about it?
For the time that this was eperienced, it was really amazing, Greg. Yes, modern compiler technology has finally caught backup with MUMPS. As an interpreter, MUMPSwas hard to beat. The run-time error support was and is far superior to any other development environment I have seen. You state that C is just as easy to learn as MUMPS. I regret to inform you that C is not that easy to learn and while MUMPS does have a few places where there is some side-effect, C has far more side-effect in its behavior. The runtime support and the potential for restartability of an application makes MUMPS a very easy learn and get involved in the language. Only a single data type makes the language much more flexible and adaptable than most other languages in a learning environment. Being able to focus on the goal is one of the strengths of the MUMPS environment. > I would turn that around: instead of using general purpose > programming languages as a specification tool, we need to learn to > develop specifications that are directly implementable. > Well, when you get one, we will look at it. Right now, this is a tool which allows the end user to direct the application development or we can play telegraph where they try to drescribe the needed application, and then REAL Porgrammers go off and interpret those requirements and force them to use an application that kind of looks like the described application in 6 months or a year later. This is the common model of development and it has been very disappointing to the end users. Better the user define their need in code that can be changed quickly to adapt to the current need, then let the REAL Programmers put in the efficiency later, but let the end user get their job done in the mean time. Machines are faster now and if it is done inefficiently but still gets done in a timely fashion, who cares? Remember that "perfection" is the enemy of "done". We should be clever enough to take these finished applications and extract the business rules as they stand so that others can see those rules as they are actually being implemented. The description seldom accurately describes how the application is actually accomplished in code. There is frequently much room for interpretation. ----- Original Message ----- From: "Gregory Woodhouse" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Monday, January 16, 2006 10:14 AM Subject: Re: [Hardhats-members] New Developers, MUMPS language syntax, etal.... > > On Jan 16, 2006, at 9:40 AM, Chris Richardson wrote: > > > It was while working for Shared Medical Systems that I learned the > > MUMPS > > language (1978). It amazed me that the MUMPS side of the house had > > a mean > > time to repair of about 15 minutes for a remote site. Their Cobol > > side of > > the house was lucky to get 72 hour turn around. Changes on the > > MUMPS side > > of the house were quick and painless (no evident recompile and > > link). The > > economies of scale are very evident. > > You mean back when you could only compile by submitting batch jobs > overnight? If that is the only argument for using MUMPS, we're in > trouble, because languages that support (if not require) > interpretation abound, and in almost all cases, recompiling is > relatively cheap. Of course, none of this means that MUMPS wasn't > ahead of its time or that the advantages you describe aren't real. > > > > The Department of Defense has their Composite Health Care System > > (CHCS I) > > which was developed from the VA's DHCP (the early name for VistA. > > In the > > compute-off that went into the DoD's effort to use the VA code > > base, there > > were 4 vendors involved. Only one vendor needed to use the VA code > > base > > (SAIC). Two of the 4 vendors dropped out after spending the $25 > > Million > > allocated for building an entry into the compute-off. It was down > > to two > > vendors, SAIC and MacDonnel-Douglas doing a more conventional > > approach. The > > MacDac entry was 67% percent functionality and their bid was $2.6 > > Billion. > > The SAIC entry into the competition was 98% functionality and the > > bid was > > $1.01 Billion. In less than the10 years of the runofthecontrat, the > > project > > was fully operational and brought in on time and on budget. > > That is certainly impressive, and even newer technologies have tended > towards large, complex infrastructure with all the resulting > problems. I think there's a growing backlash, though. > > > > MUMPS is an easy language to learn, > > Is it? This is where I don't think I agree. The language is not > terribly complex (neither is C), but does that make it easy to learn? > Perhaps it is easy to learn to write programs in MUMPS (not quite the > same thing), but the same is true of Basic, Python or Scheme. > > > and it has been easier to train > > knowledge-area specialists to program in MUMPS than to try to > > capture the > > requirements and have trained programmers do the work in abstraction. > > I think the idea of teaching knowledge-area specialists to program is > interesting, and something that needs to be explored more fully than > it has been. But there's a lot more to being a good software > developer than knowing a language (or two) and being able to put > together simple programs. > > > The > > code becomes the medium for the specification. VistA is a model > > which > > helps to standardize these requirements (at least a bit) while > > providing a > > consistant interface to the user and the application. > > > > > I would turn that around: instead of using general purpose > programming languages as a specification tool, we need to learn to > develop specifications that are directly implementable. > > === > Gregory Woodhouse > [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
