I was thinking specifically of the FOR command. It seems to take most people by surprise to have one looping command instead of three or four.
Of course the operators are overloaded as they are in most languages. MUMPS carries it a little further than most with numeric and boolean operations on strings. There's also $T and $T. Fortunately $T is not referenced explicitly all that often. :) Now here is a good argument for spelling out the entire word. Let me try that again. There's also $TEST and $TEXT. Fortunately $TEST is not referenced explicitly all that often. Many commands don't require arguments. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Monday, August 15, 2005 11:21 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Re: Command abbreviations/Re: mpsEdit - IDE for MUMPS GT.M programmers. Can you tell me about the command overloading? I know what that means in c++, but I can't think of an example in M. And yes old VistA code is ugly. I was advocating that NEW code be more beautiful and open for others. Doen't we want to attract others to the language? Why not try to bridge the gap and create code that is as similar to other mainstream languages as possible? "Q:'Y" may be more concise/clever, but "if Y=0 quit" would be understood by more newcomers and I suspect will execute just as fast. And yes I know that these two can't always replace each other. Gosh it's fun to flog this dead horse... :-) Kevin On 8/15/05, Gary Monger <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------- 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
