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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-27 01:58:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.uni2.dk!dax.net!juliett.dax.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) References: <3CB46975.90408@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <3CC59ED2.1000803@home.com> <3CC5B286.6FE61551@san.rr.com> <3CC5B9EE.32F3060@san.rr.com> From: Ole-Hjalmar Kristensen Message-ID: <7vvgadecxc.fsf@vlinux.voxelvision.no> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Apr 2002 08:57:52 GMT NNTP-Posting-Host: 193.216.12.150 X-Complaints-To: abuse@tele2.no X-Trace: juliett.dax.net 1019897872 193.216.12.150 (Sat, 27 Apr 2002 10:57:52 MET DST) NNTP-Posting-Date: Sat, 27 Apr 2002 10:57:52 MET DST Organization: Tele2 Norway AS Public Access Xref: archiver1.google.com comp.lang.ada:23166 Date: 2002-04-27T08:57:52+00:00 List-Id: "Marin David Condic" writes: > What I imagine is that a Map package spec can be designed that basically > allows for insertion, deletion & update of individual elements and contains > some kind of abstraction to walk through the elements of the map and some > means of making the data persistent. I imagine that the Version-1.0 > implementation will be something that supports reasonable access time for > average use. There can be 1024 different implementations behind it that > satisfy any particular implementor's desires if some vendor or some user > wants to do something totally different for whatever reasons. The Mark 1, > Mod 0 Grace implementation just needs to be *an* implementation that works > reasonably well. > > The danger is that this discussion is going to drift off expounding > endlessly on the relative merits of hash tables versus b-trees versus > who-knows-what. The mission was to come up with a specification that would > present the developer with something consistent with the spec for > Grace.Lists, yet provided the operations that would be needed & expected for > a map. It doesn't need to be perfect. It doesn't need to be optimal for all > uses. It doesn't need to be the final word on indexed data structures. It > needs to *exist* and be acceptable to a reasonably large majority of Ada > users. After that, it can be polished and polished and polished until it > shines like the sun. After that, any number of variations on a theme can be > composed to satisfy whatever different criteria someone may have. That's the > beauty of being able to create child packages or utilize inheritance - we > can create those variations easily. > > Maybe this is an ongoing problem we Ada programmers have - we so much want > to find the perfect solutions that we tend to forget some important > practical concerns. Lots of competing languages *already* have libraries > full of stuff - including Maps. Those competing languages don't present > every possible implementation or even an optimal implementation. What they > present is something that an implementor will find useful *today* to get > their job done. If all Ada can promise is "One day, its going to be really, > really great!!!" developers are going to continue to choose C++, Java, etc., > where the promise is: "Here's the leverage you need to get an app built fast > right now..." > For an interesting discussion about perfect vs. good enough, see the link below or do a search on "worse is better".... http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html