Responses inline below --- Jim Self <[EMAIL PROTECTED]> wrote:
> 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. [GJW] What do you think an operating system (or a GUI) does? maybe it's not an accident that I specialize somewhat in low level and evnt driven programming and also enjoy baseball. > > 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. [GJW] Not me. It reminds me of of an operating system kernel. > > >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. [GJW] Hmm...I guess I can see that. > > When I first encountered MUMPS, the thing that impressed me the most > was a lack of > features - [GJW] Yes. You'll note that I included simplicity on my list. This is a big one. > 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. [GJW] It's a mixed bag. Perl is a very complex language, but also very powerful. I can live with that. What I really don't like are languages that are just complex. > > 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. [GJW] I'm not so sure. What I see is code growing by gradual accretion, but applications, more often than not, end up being "locked in" by the original design. Introducing new algorithms, new data structures, etc. can be very difficult in code that is so tightly coupled. > > 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. [GJW] Maybe so, but is this really true today? > > 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. > [GJW] I agree. That can be a real problem, too, because it tends to exarcerbate the type of problem I mentioned above. > > >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? [GJW] I'm thinking about functional programming and languages supporting higher order functions. > > >references, > > ?? "references" doesn't have any particular meaning to me without > further context. > > >garbage collection, patterns, [GJW] I said patterns rather than regular expressions because that's the term that tends to be used in MUMPS. I'm not talking about design patterns here. > > 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) > > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- 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
