Re: [Fwd: F22 completes 11% of its Flight tests]

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Mark Lundquist wrote:
> 
> Richard D Riehle wrote:
> 
> > I would agree that _withing_ a vendor supplied package at the
> > specification level often reflects poor planning.  Ordinarily,
> > one should define the specification required for the problem
> > space then _with_ the vendor's package in the package body
> > (or even in a separately compiled subpgram) to effect the actual
> > implementation.  This accomplishes several things:
> >
> >      1) The interface is independent of the implementation
> >      2) A different implementation can be used to effect the
> >         interface,
> >      3) Vendor dependencies are hidden from users,
> >      4) With Ada 95, we can take advantage of private child units,
> >      5) We are more platform-independent.
> >
> > These are just a few reasons for hiding vendor supplied packages
> > when possible.  Granted, it is not always possible or even appropriate.

Yes, less filling AND tastes great. Done this many time before.

> >
> > [...]
> >
> > So all the fuss about _extensions_ is just that, "fuss."  Experienced
> > Ada software designers have been avoiding such dependencies for a
> > long time.
> 
> Richard, those are good points about using packages to minimize coupling.
> But it's quite beside the point of the discussion!  You're talking about
> the scope of dependencies, and how to reduce that scope through the use of
> proper programming techniques.  The discussion (the "fuss"?) wasn't about
> that, it was about the risk to a project of using components supplied by
> someone else (e.g. a compiler vendor or a third party).  I.e., about using
> them, not hiding vs. exposing them.

I believe Richard's points are to the point. Risk is about
cost and benefit. I benefit from using a vendor supplied package
but I incur cost in the form of portability. Sometimes this cost
is a limitation when the vendor supplied package is something really
special doing things not readily available on other platforms.
Most times the cost is simply extra effort when porting since most
stuff is solved everywhere by someone or another. I use the example
of socket libraries. In practical terms, every platform I ever used
has/had them but the bindings differ. So I have extra cost using
a vendor package. Following Richard's advise, I minimize my cost.

Risks are not examined in a void. The cost and payoff of taking
the risky road is compared with the cost of taking the safe road
(which usually has not payoff which is why one would be considering
the risky road in the first place).

Now I can decide based on good cost/benefit analysis. Do I grow my
own solution with significant development cost concerning things
which are not directly related to the problem at hand, or do I
take advantage of someone else's work and use a vendor supplied
package?

As a parting note, please consider that todays vendor specific
package may be tomorrows standard. 
Take the Alsys generic_elementary_functions,
and Rational's ASIS stuff. Also consider that what many customers
rely upon become de-facto standards and competitors make their
own "knock-offs." For this I present the great efforts ACT expends
to provide all those VADS and VAX specific idiosynchracies.
ACT knows that to get folks to migrate, ACT has to pave the way
with these value-added packages.

> 
> (I'm talking now about the last 2-3 messages on this sub-thread... before
> that, there were a huge number of messages trying to make sense of the
> babblings of some kind of deranged person.  The most fruitless exchange of
> messages I've ever seen.  They all pretty much looked like:
> 
>             Deranged Person:    @#&$~!   grlb,  flgmrzz!
>             Ada Person:            Excuse me?
> 
> That was where the "extension" thing came from, but nobody could figure
> out what the guy meant, and he finally went away).

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"