scs@adam.pika.mit.edu (Steve Summit) (03/29/89)
I was going to just say my piece and then stay out of the resulting fray, but there happened to be an article in today's Boston Globe business section (3/28) which discusses one of the problems underlying my advocacy of portable code. "The Software Gap: Why is software so hard? As hardware grows cheaper, faster, and more powerful; software becomes costlier, more complex, and requires higher quality." Essentially the same article has appeared in any number of publications recently. Several recent articles (here) have suggested that the authors can not afford to write portable code. As far as I'm concerned, we can not afford not to. If, at every turn of the hardware crank (and that crank turns awfully fast) the entire software industry must rise, phoenix-like, from the ashes of the previous generation, which was discarded because it wasn't portable, then this industry is never going to get anywhere, and the "software gap" will continue to widen. In article <424ce87c.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >The original poster claimed that non-portable code >should be avoided at all costs. This, too, is utter nonsense. Actually, what I said was that "All of the... extensions inevitably provided should be avoided whenever possible, not exploited." Nonportable code does have a place, but it's a small and restrictive place. Too often, it seems, a programmer who has succumbed to the urge to write nonportable code does so absolutely and, having taken the plunge, intersperses machine and system dependencies throughout the code instead of isolating them in key, low-level modules. The emphasis should be on writing clean, portable code whenever possible, adopting machine-dependent efficiency tweaks only if absolutely necessary; instead of the other way around -- hacking away unmercifully and writing portable code only as a last resort. It is possible, and an enlightening exercise, to take just as hard a line against "bad" code (where "bad" is unportable, or cryptic, or unmaintainable) as is often taken against code that is "slow." Just as Messrs. Driscoll and McDonald cannot tolerate code that is not micro-optimized to match its particular environment, I cannot tolerate code which is unnecessarily obtuse or unportable. We'll just have to find some way to have our cake and eat it too -- to isolate the critical portions of the code in such a way that they can be optimized (only if necessary!) while leaving the larger body of code pristine. Such a partitioning can be achieved 100% successfully far more often than is commonly imagined. It may take a bit more work in the short run, but to do so will pay off handsomely in the long run. Writing system-specific code at every opportunity simply is not an option. Steve Summit scs@adam.pika.mit.edu