Gregory Woodhouse wrote: >I disagree with you that the issue here is one of what is easier >to read. Most MUMPS programmers are simply *accustomed* to >abbreviated commands. The abbreviated commands are not inherently >easier to read, only more familiar.
Nonsense. Although non-MUMPS programmers would obviously be unfamiliar with both the syntax and the intrinsics of the language (standard commands, functions, and variables), any programmer that prefers to read the standard elements of MUMPS in the long form can write them that way and read them that way (independently) if they so choose. Virtually everyone I have ever known who has spent enough time with it to master the language chooses the short form almost all of the time. Additionally, anyone who reads MUMPS code written in whatever style by other programmers can easily view it in whatever style they prefer with a utility such as the routine viewer that I provide in M2Web. When I started with MUMPS about 24 years ago, I started out by reading existing code extensively, including CoSTAR, Fileman, and many other public domain sources that were available at the time. The language certainly looked strange and unfamiliar to me at first, but there was a utility for pretty-printing MUMPS code that was included in the %INDEX* utilities (precursor to XINDEX*, written by Bob Lushene if I remember correctly). Not only did it expand all the commands and intrinsic functions and variables, it also broke up the code so that only one command and one argument was displayed per line. I thought it was a wonderful learning aid and used it for viewing everything for a while, but after a few weeks I couldn't stand the unnecessary verbosity, so I modified it to only expand one line of code at a time as needed. As I became more familiar with the language, I used even that less and less often. The problem was that a routine that could be viewed on a single page would be expanded to 10 pages and it would be much less readable because the extra space would make it more difficult to grasp the overall logic of it - losing the view of the forest for the trees. Now, of course, we have much better facilities for viewing source code. Using font characteristics such as bold and italics and varying background and foreground colors to differentiate syntactic features such as quotes and comments and providing active links from subroutine and extrinsic function calls greatly improves the ease and speed with which you can read and confidently understand large amounts of unfamiliar code. --------------------------------------- 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
