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