One way around this would be if the algorithms could be encoded in a
non platform specific way into the images themselves. But the more
complex code would probably add 10+ megabytes!
Only if the coder were inept. That seems
extremely inflated to me.
Add 10+ megabytes where, and of what? Of source code?
Machine language? Memory image? Average resident set
size of the running process--and if so, working on what data?
=================================================
Similarities should be represented in code, differences in data.
=================================================
If you code up all possible differences instead of running off a
table-driven algorithm whose differences are stored in that
table, then of course you will incur astronomical levels of code
bloat. If you do it properly, you will not. Every programmer
who merits the title instinctively factors out similarities. When
you factor out similarities, not only do you shrink your code
size, you also create a program that is dramatically easier to
maintain and to manage. It may well run faster, too.
Those of us who learned to write full-sized programs, even
operating systems, within address spaces of only 64k or smaller
--yes, I said kilobyte not megabyte--learned that not only
was small beautiful, but the only game in town. Those lessons
are still relevant today, whether we can throw another gigabyte
of memory on the problem or not. An untidy program is an
untidy mind, and you do not want to suffer under what code
an untidy mind produces.
Being a programmer is a strange thing in this regard: unlike
many and most other professions, where the qualitative
product of their labors varies by perhaps 5-25% each level
going from an unskilled inept up through a poor to a fair to a
good to a great to at last a world-class adept, and where
such differences are not always apparent. With programmers,
the difference is much greater, and must more obvious.
A good programmer will easily produce code that's of
10x the quality of a merely average one's, although financial
compensation will never increase accordingly. A poor
programmer, of whom there are many, will create things
that are staggeringly inferior in quality. And yet these people
muddle through their jobs, afflicting the rest of us with
their disabilities, and still being paid not much less than an
average programmer would be paid. Even if you hired
10 programmers of "poor" grade, they could never produce
something a good, let alone great, programmer could produce.
Hiring 9 women won't get you a baby in 1 month, but it will
get you 9 babies in 9 months. With programmers, it's more
like preschool finger-painters: no matter how many poor ones
you have laboring for however long you will, never shall they
produce the output of a Michelangelo or a Da Vinci. Give me
just one gifted programmer over 100 pedestrian ones any day.
Another 10+ megabytes of program? Only if you employ
artless and ungifted programmers unable to see the forest
for the trees.
Alas that these sorts are never in short supply!
--tom
I also said you'd be along at some point with an accurate statement. 
