Greg Woodhouse wrote:
>I guess what I had in mind with the baseball analogy is to rate

One of the best things about MUMPS for me is how very little it reminds me of 
baseball. ;)
Sitting around doing nothing for hours while watching a few dozen men mostly 
doing nothing
waiting for a rare moment of relatively intense action and then more waiting.

Baseball reminds me more of working with compiled languages, like FORTRAN, back 
before we
had PC's and you submitted your programs on punch cards and then you might have 
to wait
for 12 hours to get them back (unless you submitted your programs in the middle 
of the
night after everyone else had given up.

>features in terms of how much they give you that might not be (easily)
>available in another language.

MUMPS reminds me more of soccer. It's not so much the individual features of 
the language
that are impressive, but the overall package and how it facilitates ongoing 
development
and continual active participation from individuals with varying skills and 
backgrounds
and interests.

When I first encountered MUMPS, the thing that impressed me the most was a lack 
of
features - things in other languages that mostly seemed to get in the way and 
distract me
from being able to focus on the problems I was given and providing solutions to 
them.

MUMPS had a simple model of computing that encompassed multi-user access to 
data of
arbitrary complexity and size. The data model felt elegantly simple yet 
incredibly
open-ended and the whole system seemed to encourage the development of simple 
solutions to
problems that could then be easily refined and scaled over time as needed and 
as the
problems came into better focus.

At that time, MUMPS was the whole operating system and it seemed to promise 
easy mastery
so that you could do everything in MUMPS that was needed from top to bottom for 
developing
a comprehensive integrated Medical (or otherwise) Information System. It 
offered a
simplicity and low cost optimized performance and reliability that meant that a 
handful of
programmers could develop amd support an information system that with a 
different platform
would require dozens of programmers and orders of magnitude higher costs for 
hardware and
software licenses.

Of course, that was before even the concept of GUI or object programming had 
spread
outside of a few research labs. Now it seems that many things that were once 
done entirely
in MUMPS on a dumb terminal are better handled by the operating system or in a 
web browser
or by a myriad of other utilities or applications written in other languages.


>What I refer to as "home runs" in language design are few
>and far between. I would put recursion in this category along with
>hashes (think string subscripted arrays), functions as objects,

What do you mean by "functions as objects"? Did you mean functions as object 
methods, or
were you thinking of a different capability to inspect and dynamically alter 
functions in
a live computing environment?

>references,

?? "references" doesn't have any particular meaning to me without further 
context.

>garbage collection, patterns,

Again, "patterns" seems too general of a concept to think of as a feature of 
most
programming languages. Recognizing patterns in the problems you work on and 
reflecting
them in your code is one of the most essential aspects of higher level 
programming. Are
you thinking of something in specific?

>the MERGE command. That's a big one.

I agree that that is a nice feature to have in MUMPS. It seems very much like 
setting a
variable or property of an object equal to another object.

>I am very much impressed by the fact that a node in
>a MUMPS array can have both a value and children. That DOES make it
>easy to implement algorithms that, at th very least, would require
>auxillary data structures in another language.

All of the standard features of MUMPS globals are (or soon will be) reflected 
in Steve
Zeck's Db-GTM Perl module.

I am interested in building on that to reflect the abstract features of data 
records in
Fileman compatible databases.

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)


-------------------------------------------------------
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

Reply via email to