not safe at all

[Tim Daneliuk]

Alex Martelli wrote:
> 
> "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...?
> 
><SNIP>

No.  I meant that in every  commercial software/systems environment I've
every seen, the portability of the *programmer's* skills was more important
than the portability of their final work product.

<SNIP>

> > 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.
> 

You are dead wrong about this.  Not all engineering problems
can be fixed with money - some are just plain impossible at
ANY cost.  Portability can fall into this category.   
It is (or was, and possibly still is) *impossible* to write
portable code, for instance, across IBM TPF (for which no 
high-level language compiler existed), Tandem Non-Stop (which has
a VERY different programming model than most other OSs), 
and Unix AND still meet the performance critera we were expected to
hit.   

Actually, in the case of TPF at the time, it was *literally*
impossible to write portable code - everything was written in 
IBM/3090 BAL (assembler) cuz that's all there was.  Short of 
writing a VM to run BAL on other machines or a 'C' compiler for
TPF (which, at the time, would have been a joke considering the
performace requirements we had to hit - *everything* on the mainframe
had to be hand tuned) there was no way to do it.  

Portability is not simply an artifact of willingness to spend money,
though that  certainly is a factor (as is time).  It is a
consequence of good requirements, good design, and similar-enough
target environments to make it feasible in the first place.   It's
hard enough to do when you have these "similar enough" systems, like,
say, Unix and Win2K.  But how are you going to port your nice, clean
C program to a machine that speaks EBCDIC, has no stack, has no
shell as you understand it, does not implement fork/exec, does not have
sockets, each CPU is  running at 100% utilization very
second of the day?   Oh, and those are the fastest CPUs for that
sort of computation that money can buy. (These conditions have 
all probably changed by now, but that was the case then.)


> 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

This is a lovely precept that happens to work enough
of the time that people start to assume it is always true.
Abstraction layers ARE a convenient and helpful design tool
and they DO promote better portability.  However, you can
forget all that if you've ever had to make performance your
first consideration.  Again, in original example I gave,
performance and uptime was all that mattered because we
were already running a 7-way CPU cluster of the biggest, baddest
mainframes available.  When guaranteed response time and/or
human safety and/or huge sums of money are at stake, no one
gives a Tinker's Damn about portability or any of the other
sacred cows that get flogged in "Software Engineering" community.
Get yourself invited to the development center at one of
airlines reservations systems or VISA or MasterCard and
you will discover an entire world where everything you were
taught turns out to be wrong.  In other words, software that
is not neatly layered is not necessarily badly designed,
it may well be purpose-built that way.


<SNIP>

> 
> > 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

None of whom give a damn if your code is portable (unless you're
selling programming tools like compilers) or how elegantly
architected it might be - they just want your application to run 
on their system.  How it does so, is your problem, not theirs.





-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com