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,5c4627b775acf6be
X-Google-Attributes: gid103376,public
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
Subject: Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?
Date: 1999/12/05
Message-ID: <82dk7t$5ka$1@birch.prod.itd.earthlink.net>#1/1
X-Deja-AN: 556854674
Content-Transfer-Encoding: 7bit
References: <38497235.D8339C38@netwood.net> <82btoo$8201@news.cis.okstate.edu>
 <82buhr$8q61@news.cis.okstate.edu> <38498EB1.306427C8@netwood.net>
 <82c7mu$a2g1@news.cis.okstate.edu> <3849E314.6281FC6D@netwood.net>
 <82cors$9281@news.cis.okstate.edu>
X-Posted-Path-Was: not-for-mail
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-ELN-Date: 5 Dec 1999 12:02:05 GMT
X-ELN-Insert-Date: Sun Dec  5 05:05:13 1999
Organization: Ada95 Press, Inc.
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-12-05T00:00:00+00:00
List-Id: <comp.lang.ada>


David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:82cors$9281@news.cis.okstate.edu...
> On Sun, 05 Dec 1999 03:59:16 +0000, E. Robert Tisdale <edwin@netwood.net>
wrote:
> >David Starner wrote:
> >
> >> On Sat, 04 Dec 1999 21:59:13 +0000,
> >> E. Robert Tisdale <edwin@netwood.net> wrote:
> >>
<snip>

> >But it is a very bad way to get a standard API.
> >It's better to design an API that liberates library developers
> >to implement the library as they see fit.
>
> I disagree - it's better to design an API that lets programers
> do what they need, and lets library developers make a efficent
> implementation, even if they don't have much choice in how to
> do it. For example, the C function memcpy has a decent interface,
> but there is one way to implement it. I fail to see how changing
> that would improve memcpy.
>
I would say that an API should liberate its clients' programmers
to concentrate on their client application, by presenting a good
abstraction of the functionality provided by the library.

If that makes the implementation more difficult, then so be it.
Even, performance, in my view should play a role secondary to
the presentation of a good abstraction, given that today the costs
of machine performance continue to plummet, while the cost of
software development, and the cost of correcting software errors
continue to escalate.

<snip>