From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d3bcc180a8b0eea4 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: [Fwd: F22 completes 11% of its Flight tests] Date: 2000/01/26 Message-ID: <388FA484.EB74834C@Raytheon.com>#1/1 X-Deja-AN: 578121861 Content-Transfer-Encoding: 7bit References: <387C8859.621FA20B@netscape.net> <387CC1C0.4C57E34C@quadruscorp.com> <387CEE4A.3965@Ganymede.com> <387F8E50.11D27E14@quadruscorp.com> <85oclj$nbp$1@nnrp1.deja.com> <387FCA73.3A61@Ganymede.com> <85ok6v$iee$1@ssauraab-i-1.production.compuserve.com> <3880CCC7.261957BC@quadruscorp.com> <38835B50.B2EF88C6@quadruscorp.com> <38838D5A.9EB9F452@maths.unine.ch> <864hrd$546$1@nnrp1.deja.com> <388E014A.B8F87F5@ebox.tninet.se> <86l6nn$mhj$1@nntp4.atl.mindspring.net> <388F41D8.981FDF54@rational.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Aerospace Engineering Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-01-26T00:00:00+00:00 List-Id: 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!"