Stephen said:
From lurking on this most excellent newsgroup, I have garnered that an
expressed benefit of having a standard is portability of code.
I see a lot of open source endeavors that inspire my awe, but I can't see
how the authors get paid, so they don't much inspire my ambition for
pursuing perfection, which is inate nonetheless.
In real life, how many of you knowledgable people are ever actually
consigned to write code that will port to very many systems, if even more
than one? Historical anecdotes aside. Let's say within the last five
years.
Portability is just one of many desirable attributes
of a program, and it is not always the most important.
Some others are correctness, capability, maintainability,
speed, scalability, ... the list goes on. The main thing
to keep in mind is that these attributes are sometimes in
conflict, and the conflict is not (and should not be)
resolved the same way in every situation. Even correctness
is not always paramount -- in some real-time situations it
may be more important to get an approximate answer *right
now* than to get a fully accurate answer two seconds late.
The engineer is always performing a balancing act.
That said, portability is more desirable today than it
used to be, and is becoming still more desirable with the
passage of time. The reason is economic: Once upon a time
computer power was expensive and programmers were cheap,
but today skilled labor is expensive while computers have
become cheap. Once upon a time it made sense to use a lot
of labor to move a program from Machine A to Machine B, so
that the program could take advantage of A- or B-specific
features to run more efficiently or compute more accurately.
Today, it makes far less sense to resort to the machines'
idiosyncracies; it's cheaper to waste a few cheap CPU cycles
than to try to recoup the extra cost of expensive labor.
Again, though, I emphasize that none of these desirable
attributes trumps all the others in all situations. If you
find yourself writing for somebody's Web-enabled toaster you
may sacrifice some portability to squeeze the code into just
one ROM chip instead of two. Reducing the per-unit cost by
a buck-fifty on a manufacturing run of a million toasters
saves a million and a half dollars, which (just between the
two of us) is more than enough to buy a week of *my* labor.
Finally, "portability" is not a Boolean attribute; I do
not even believe it is one-dimensional. "Portability" may
be best characterized in terms of a likely set of target
platforms (which amounts to a guess about the future of the
program) and the labor required to get the program working
on those platforms (another kind of guess, whose difficulty
is described in "The Mythical Man-Month"). When we say that
this or that construct "is portable" or "isn't portable,"
we're using a kind of short-hand for considerations that are
much fuzzier, much harder to characterize than "is/isn't"
makes them sound.
Do I, personally, write "portable" code? Yes, always!
My code is "portable to all the systems of interest," just
like everyone else's. The question becomes whether I've
got a good idea of the universe of systems that are or will
eventually become "interesting" ...
