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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a644fa9cd1a3869a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-14 06:55:40 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!sfo2-feed1.news.digex.net!intermedia!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9sn4qm$13g29j$2@ID-25716.news.dfncis.de> <3BF140D9.611DE43@brighton.ac.uk> <8ifI7.23379$xS6.36874@www.newsranger.com> <3BF26AAC.C0830E5B@brighton.ac.uk> Subject: Re: List container: Insert and Delete Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Wed, 14 Nov 2001 09:55:36 EST Organization: http://www.newsranger.com Date: Wed, 14 Nov 2001 14:55:36 GMT Xref: archiver1.google.com comp.lang.ada:16502 Date: 2001-11-14T14:55:36+00:00 List-Id: In article <3BF26AAC.C0830E5B@brighton.ac.uk>, John English says... > >Uh huh. So "hard to use" is one no-no. Are there any others that spring >to mind? Does "hard to use" apply to all the other libraries out there, >or are there other reasons for not using those? What got Booch into the "hard to use" category was its reliance on hierarchies of generics. Unfortunately, if you throw that out, it also throws out just about every industrial-strength component library out there. I think the basic problem is that pretty much everyone has approached the problem either from a purely industrial perspective or from a purely acedemic perspective. Thus we end up with a bunch of libraries that might be great for their designed enviroment, but suck for the other. What we are shooting for I believe is something that can be shipped with Ada compilers (as part of the language, or as a cannonical add-on), which will be usable for *both* purposes. That obviously means it isn't going to be ideal for either purpose, but it should be usable most of the time. People will still be free to go get one of the other component libraries if they find that this one just isn't quite up to their needs. >I feel that knowing why existing libraries don't cut the mustard might >help in designing something that does... I think (I hope anyway) we've already been through that process. Perhaps listing some of the decisions and goals we arrived at on a webpage would help newcommers to the discussion (and those who haven't had the fortitude to follow every post :-) )? We could certianly use your input in this process. Right now I believe Ehud is the only active participant from acedemia, and I'm afraid things might be getting a bit too much of an industrial tilt as a result. For instance, I'm more interested in your views on the subprogram and type names than I am with most people's, because you and Ehud are the ones who are charged with teaching people how to think about lists, which presumably includes proper terminology. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.