It's a matter of practical use. Anyone taking up the language has to deal with things as they are. The single letter version of commands and system functions is nearly universal, and the code base is not likely to change.
Some tools are available, but will they translate everywhere you need it and in conjunction with other tools you want to use, like a Data Dictionary lister? Its not a matter of which is easier or faster, both are easy enough and fast enough, and soon learned. It's just not really much of a problem in comparison to more serious readability issues that abound, and are created every day. For folks new to MUMPS there are many other stumbling blocks. Like the order of precedence of operators, dynamic typing/type coercion, overloading of commands, accessing the database, naked references, indirection, $TEST not being stacked, etc. MUMPS is substantially different from most languages no matter how you spell the commands. And for the most part the newcomer has to look them up anyway. A good place to do so: http://www.jacquardsystems.com/Examples/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Gray Sent: Monday, August 15, 2005 4:06 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Re: Command abbreviations/Re: mpsEdit - IDE for MUMPS GT.M programmers. I really think that for anyone new to Mumps that having the commands spelled out would be easier. I doubt we need the study for that. I think the only question is whether somebody who is fairly good at Mumps programming can actually read and understand the logic of unfamiliar code faster if the commands are spelled out or abbreviated. Perhaps it is just what we are used to. Jim Gray ----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Monday, August 15, 2005 7:59 AM Subject: [Hardhats-members] Re: Command abbreviations/Re: mpsEdit - IDE for MUMPS GT.M programmers. The only way to "prove" which is better would be to do some sort of controlled study of persons new to M and asking which way is easier to learn. But as a newcomer myself, I think that making M as similar to other languages as possible is desirable. And I don't know of any other modern language that uses single letters for its commands. Beauty is in the eye of the beholder... :-) Kevin On 8/15/05, Gregory Woodhouse <[EMAIL PROTECTED]> wrote: > I suspect that one problem is that since MUMPS is not highly regarded > in some circles, we MUMPS programmers have a tendency to be overly > defensive at times, and respond negatively to suggestions that would > tend to dilute what e perceive as MUMPS' distinctiveness. This is > unfortunate for a number of reasons. One, of course, is that it > doesn't "play well" outside the community. But a more serious issue > is that it stands in the way of properly appreciating what MUMPS has > to offer and, to be honest, it has a tendency to lead us to > (unintentionally, of course) undersell ourselves. > > If I were teaching programming, would I use MUMPS? No. But are there > features of the language that I think could make it valuable both > pedagogically and as a research tool? Yes, absolutely. There are > simply concepts that are both difficult to teach and difficult to use > in languages such as C. I like C very much, and it is a language I > would encourage everyone to learn, but MUMPS includes facilities not > present in languages like C that can be extremely valuable. It is no > accident that dynamic languages like Perl and Python have remained so > popular -- they include language features that have proven to be > extremely valuable in some situations, and the same is true of MUMPS. > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "A practical man is a man who practices the errors of his > forefathers. -- Benjamin Disraeli > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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
