not safe at all

[Alex Martelli]

"Tim Daneliuk" <tundra at tundraware.com> wrote in message
news:3B509C1F.B2E7ABD6 at tundraware.com...
    ...
> Sure, there are places where portability is important.  And portability
> is not a "Yes" or "No" things - there are degrees.  But the most
> important thing that needs to be portable are *the skills of the
> people* so that they can be used in many different roles.

As in, taking a world-renowned specialist in surface-modeling, and
ensuring he wast^H^H^H^H spends enough time to be able to
program a GUI, or knows enough SQL to write some queries, or...?

Thanks, but NO, THANKS.  One advantage for a software development
firm to grow to middling-size (to be offset against several minuses)
is being able to AFFORD a few all-out specialists in those areas that
are key competitive differentiators for the firm's products.  For us,
that means specialists in such things as 3-D kernels, surfacing,
surface/solid
integration, and PDM needs of middle-sized mechanical engineering
firms.  It's *NOT* a problem if the PDM specialist doesn't know what's
a NURBS, and the surfacing specialist doesn't know what's a BOM --
it DOES matter that the firm as a whole has, say, a dozen such key
people in the right areas out of a couple hundred developers -- people
able and eager to concentrate on very specific, narrow, focused
domains, with the total unremitting concentration and enthusiasm
that such specialists tend to bring to their work.  Their skills need
not be "portable" to other areas or roles -- they need to be allowed
to concentrate on what they're exceptionally good at, in order to
develop the innovations that spearhead new products and versions.
(If and when such guys *WANT* to branch out in other fields, it's
of course clever to support their explorations -- that may well be a
spring of innovations too, among other issues -- but it's exceedingly
rare that a specialist WANTS to leave his or her specific field, where
he or she always seems able to find new fascinating challenges and
new worlds to conquer).


> DEC once estimated that there was something like an 8 or 10 to 1
> ratio of the cost of owning code vs. the initial cost to produce

May make sense, depending on the code's longevity (related to
the speed of advances in the specific field).

> the code.  The ongoing reliability and maintenance of software and
> systems tends to be way more important than portability of the code
> itself because that is a relatively lower cost to produce the code
> than to maintain it.

But porting, when it's needed, is part of the "cost of owning", not
of the "cost of producing".  Raising the producing-cost a little bit,
by caring about portability right from the start, may significantly
lower the owning-cost, depending on porting-needs -- which,
again, will in part correlate to longevity.  Code that you'll pension
off in 6 months may easily never need to be ported -- code you'll
carry around for 10 years is VERY unlikely to not need porting, in
a platform market subject to reasonably fast innovation.

So, the dominance of ongoing costs vs initial ones doesn't indicate
a LOW importance for portability -- indeed, the very contrary!


> Anyway, our code, *by intent* was *not* portable.  It couldn't
> be portable in any practical sense because the underlying
> infrastructure paradigms are really different between, say TPF,

Underlying infrastructure paradigms do tend to differ deeply
when portability is a problem (otherwise, portability is basically
free and it would be very silly to ignore it:-).  But it's a serious
error to claim that a program cannot be portable if the underlying
infrastructure paradigms differ widely!  Such underlying differences
just raise (a bit) the COST of portability, because you have to
write most of your code to a higher-level abstraction and also
implement that abstraction on different underlying platforms.

But the costs only grow by _a bit_, because good software IS
'layered' anyway -- levels of different abstraction built on top
of each other.  You just have to ensure your lowest levels are
designed in a way that is decently decoupled from specific
bits of infrastructure -- often not MUCH harder than coupling
them heavily and strongly, and often worthwhile anyway (if
the lower-level quirks aren't ALLOWED to percolate upwards
and pollute the higher-level architecture, that may often be
all to the good of the higher-level cleanness and resulting
productivity in development and maintenance).  A long time
ago, in a galaxy far, far away, we had different GUI's running
on top of WIDELY different infrastructure paradigms -- the
bare paint-pixels-yourself approach of a now-obsolete HP
proprietary minicomputer, Apollo's Domain, Dec VMS (I
forget how their GUI subsystem was called), an early release
of Windows, some X or other (I think it already was X11, but
I'm not sure)... and we had not taken the trouble to design
a _portable_ GUI architecture.  Fortunately, at one point, we
did, even though it did mean more than refactoring -- it was
a big-bang junk-and-rewrite of a lot of stuff, given how badly
we had allowed non-portability to 'percolate upwards' -- the
cost of porting and maintaining on (at that time) half a dozen
platforms was killing us (we were much smaller then, so the
cost was a really large portion of our total investments).

The resulting portable architecture, highlighting *decoupling*
between portable parts (the higher-levels, amounting to a
VAST majority of the applications) and non-portable ones (the
lower-levels, handled by *specialists* of both the platforms
AND the subject-area -- this early specialization freed most
developers from having to know or care how you paint a pixel
or respond to a button clic on any given platform, gave us
higher-quality GUI's AND better application-logic, and paved
the way for our growth) served us well for years.  When, much
later, we jumped on the Win95 bandwagon (having sniffed out
that this cranky unreliable OS bid fair to conquer engineers'
desktops, whether we liked it or not), we gained "native Win32
look and feel" faster and more smoothly than our competitors,
and with the involvement of less than 10% of our developers --
all the others could still (lucky them) develop on Unix, respecting
our in-house portability rules, and "it all just worked".

GUI's are one example, but I have others, from the same bunch
of real-life experiences, in such things as RDBMS's and network
protocols.  Attention to portability, mostly by designing intermediate
layers and letting most everybody program to those layers while
a few specialists slave away at implementing the layers on top
of various platform-quirks, has always stood us in VERY good stead...

> more interested in creating competitive and distinctive market
> advantage than serving the abstract idea of portability.

What gave you the idea that anybody around here is interested
in "serving abstract ideas"?  I'm interested in serving *our
customers*, all 10,000+ of them at last count -- ensuring
the applications they buy from us (or actually, these days,
_rent_ -- we've successfully transitioned to a subscription
business model) have very good architecture (including the
careful layer separation that also ensures portability) is a
means to that end (which in turn is a means to the end of
making a whole lot of money of course:-).


> I think code portability really only becomes an issue if it
> is a first-order component of the economics of a company.  For example,
> if you sell compilers, portability is probably pretty important.
> OTOH, if you write drives, it is not much of an issue.

And if you write mechanical CAD and PDM in the current
market, it may not SEEM much of an issue -- if you're too
young to remember all your former-competitors killed by
having put all their eggs into one non-portable basket, to
exploit some nifty-looking doodad in a platform that then
became defunct too fast.  Fortunately, enough of our guys
used to be the best developers from just such quondam
competitors, so I don't think they're likely to forget:-).


> > -- they claim speed-ups
> > of about 60% overall, more solidity, etc, as a consequence.  If that
>
> Speed-up, I believe.  But "more solidity" by switching C++, I doubt.
> That probably has more to do with 2nd generation software being
> better than the 1st.

Or else the claim is unwarranted -- who knows, but it wouldn't
be the first time that marketing overclaims something:-).


Alex