--- Kevin Toppenberg <[EMAIL PROTECTED]> 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.
That's actually not terribly surprising if what you are trying to do is retrieve a single value or perform a similar operation. But if someone were to come along and change the way data is formatted (e.g., using name components instead of the .01 field, or perhaps encoding non-ASCII characters), then your old code would then be broken. The point (well, one of them) of using proper abstractions is to protect the intgegrity (and maintainability) of your system. > I think that says something significant I do, too, but perhaps for a different reason. MUMPS arrays are already sophisticated data structures, so including them in the language itself make it easy to write code to do what could be quite a bit harder in other languages. The real point is that you're not really working at such a low level of abstraction after all! Consider what would be involved in doing a similar lookup in an ordinary file using C. First, you'd need to do a lookup in an index to find the record offset, then you'd need to seek to that location in the file, read a fixed number of bytes, and then extract the record, copying it into another array you had allocated. Oh, and by the way, that index would most likely be a B-tree!) Most of these details are hidden from you because MUMPS isn't really such a low level language, after all. I know that sounds like a contradiction to what I was saying earlier, but it's not because the fundamental abstraction provided by MUMPS is different from the basic abstraction supported by Fileman (the file). The difference is close in spirit to the distinction between structs in C and objects in C++. Yes, C is easier than C++, but you may well find that if you're working in C, you have to spend a lot of time implementing the kinds of abstractions supported by C++, Java, Delphi, VB, or another language. If you don't need them, then the added complexity of the language seems like just so much "dead weight". On the other hand, if you do need them, having language level support can be very valuable. > ... > But > set name=$piece($get(^DPT(1234,0)),"^",1) > is just easier than > do GETS^DIQ(200,1234_",",.01,,"TMGOUT","TMGERR") How about >W $$GET1^DIQ(200,".5,",.01) POSTMASTER It's easier, but it's still an API you need to learn. I can understand why I a programmer might prefer something like >W $P(^VA(200,.5,0),"^") POSTMASTER because it uses constructs of the underlying language only, without any extrinsics. Even so, there's some hidden subtlety here: How did you know that name of user N would be stored in the first "^" piece of ^VA(200,N,0)? You wouldn't need to know this to use the $$GET1^DIQ call. So, I suppose it's kind of an even swap. (The patient file, stored in ^DPT is file 2, but that's a trivial detail, and has nothing to do with your main point.) > (more code here to parse TMGOUT) > (Just to do this example, I had to pull out the manueal to get the > parameters correct.) > > But how about a compromise? > Set up a special category of platform-independant-code. Programmers > can $order through an index if they want, but then they will fail to > qualify as XYZ type code. Then, there would need to be some reason > that users would want to have their code be XYZ status. > > Kevin Sort of like "100% Pure VistA"? :-) But my point isn't to make value judgments here. Rather, the type of developments I describe here are things that I believe are needed for the long-term success of VistA. Others may disagree, but I hope I've made reasonably cogent arguments. === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ------------------------------------------------------- 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
