not safe at all

[Tim Daneliuk]

Alex Martelli wrote:
> 
> "Tim Daneliuk" <tundra at tundraware.com> wrote in message
> news:3B4F743C.66778F9F at tundraware.com...
>     ...
> > Furthermore, bear in mind that code "portability" is no where near as
> > important in the commercial sector as it is in academics.  Commercial
> 
> That depends on the state of the market.  Just a few years ago, it
> would have KILLED us if our CAD applications didn't run portably
> between VMS, Apollo Domain, and many versions of Unix -- each
> OS accounted for an important segment of our customer base.
> 
<SNIP>

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.

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

I once was Chief Technologist for a company that did communications
messaging middleware and oversaw its transition to 20+ operating
platforms that were all over the map in OS and comms protocols.
(All IBM Mainframe, All the Unixes, MS-DOS, OS/2, Win16, Win32,
TCP/IP, SNA, NetBIOS, Novell and many others were supported in
a wide variety of combinations and configurations.)

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,
Unix, Stratus VOS, and Tandem Nonstop as they run comms over
VTAM/SNA, Sockets/TCP/IP, Novell, and so forth.  We were far
more interested in creating competitive and distinctive market
advantage than serving the abstract idea of portability.

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.

> 
> 
> I'm not getting into the C++ flamewar you're trying to unchain --

Sorry, that was not my intention.  Apologies to all if it seemed
that way...

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

> is an example of C++ "dying a slow death", I think Mark Twain's
> well-known dictum may apply.

I did say it would be "slow" ;)

> 
> I _do_ agree that C++ is too complex for the human brain and
> thus should only be used sparingly (for system interaction and
> top-speed components -- but do notice that those components
> ARE part of large commercial applications... and many people
> still do not realize that multi-language applications are the
> way to go, thus, needing maybe 10% of the app to be in C++,
> they go ahead and make or rewrite it ALL in C++, rather than
> make it 10% C++ and 90% Python...:-).
> 


Absolutely right.

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