Kevin wrote: >Well, the more I have used M, the more I find that it is much easier >to do the low level coding than it is to use the higher level >interface. I think that says something significant--
I agree. One thing it says to me is that there could be better API's for programmers. >since it is usually harder to do lower-level coding E.g. c++ is easier than >c, >which is easier than assembly, which is easier than machine byte code. But >set name=$piece($get(^DPT(1234,0)),"^",1) >is just easier than >do GETS^DIQ(200,1234_",",.01,,"TMGOUT","TMGERR") >(more code here to parse TMGOUT) >(Just to do this example, I had to pull out the manual to get the >parameters correct.) The straight forward low level solution is certainly easier for simple operations on a small number of data fields by a programmer who is familiar with the details of the database layout. The resulting code is almost certainly faster and it may even be more quickly written and more easily debugged. Unfortunately, writing code at this level is less accessible to others, especially non-programmers, and even to the original programmer after a few months or a few years, and it becomes less desirable with a larger number of fields or a more complex and sophisticated user interface where it would be desirable to systematically bring other features of the field definitions to bear, such as field size, display type, help text, input transforms, cross reference updates etc. Working with magic numbers, such as piece positions or field numbers, quickly becomes confusing and difficult to remember. Think about the code for a common data entry form or a columnar report with 10 to 20 fields. The code for this could get quite voluminous and unwieldy if written out at the low level of global locations. On the other hand, if the data fields are well defined in a data dictionary, the code for presenting a whole data entry form and processing the data submitted from it can be generated from little more than a list of field identifiers. --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
