Here, here - well stated. One thing that needs repeating is that one of VistA's initial design specifications (and one that still exists) is that ALL application code be implementation and platform independent. M vendors and OS vendors may not prefer that the VA have been so insistent on this point. The VA was heavy pointing the M vendors in the area of Structured System Variables (SSVNs) within MDC prior to the end of MDC for this very purpose. Please, Please do not take this response as a voice for the resurrection of MDC. Without a strong M vendor market, reviving MDC would not be in anyone's interests.
----- Original Message ----- From: "Greg Woodhouse" <[EMAIL PROTECTED]> To: "Hardhats" <hardhats-members@lists.sourceforge.net> Sent: Friday, July 29, 2005 3:58 PM Subject: [Hardhats-members] On portability It's been said that computer science is the science of trade-offs (time vs. space, clarity vs. efficiency, bandwidth vs. delay, read time vs. write time, etc.) Portability is simply another area where you end up making some sacrifices (e.g., in direct mapping of operations affecting files, processes and so forth to operating system primitives) to achieve another goal. Bhaskar has rightly pointed out that the I/O and process models on different systems vary from one another, sometimes significantly. What is to be done? One option is to write system specific on every platform. This is not unreasonable, but it is not without cost. On the positive side, I/O and interprocess communication can be very efficient. On the negative side, porting your software from one platform to another can require a significant (even very significant) amount of work. Introducing common abstractions that work the same way on all platforms is another option. On the positive side, it is only necessary write your code once and, in theory, run it anywhere the platform is supported. On the negative side, your code may be slower, not just due to the overhead adapting to the interface, but due to the problem of writing libraries that may need to perform complex manipulations to get different systems to "look the same". An additional problem is that your code will almost certainly not have the same degree of flexibility as code written in C or another language providing direct system access. You may often find there are things you want to do, and which you know are supported at the operating system level, but which simply are not supported in the language you use. So, where do you strike the balance? There is no one right answer (which is probably why we have so many programming languages to choose from). Ultimmately, it comes down to looking at the competing goals of speed, flexibility, robustness, system footprint, price, and market share (Do you want something that will only run a 6 CPU Dodekium running MAXIX?) === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members