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,714a8558b02b32bb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-23 05:34:35 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshosting.com!news-xfer1.atl.newshosting.com!216.196.98.140.MISMATCH!border1.nntp.ash.giganews.com!nntp.giganews.com!pd7cy2so!shaw.ca!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <401122E6.4010405@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GUI was Re: why Ada is so unpopular ? References: <100tkcshhdi686a@corp.supernews.com> <400FD340.3080603@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 23 Jan 2004 13:34:34 GMT NNTP-Posting-Host: 209.165.26.148 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1074864874 209.165.26.148 (Fri, 23 Jan 2004 05:34:34 PST) NNTP-Posting-Date: Fri, 23 Jan 2004 05:34:34 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:4708 Date: 2004-01-23T13:34:34+00:00 List-Id: Yeah, but that's still running smack-dab into my hypothetical objection to a matrix math package - that solving an N by M matrix where N and M are big is just plain going to take some time. Does that mean we shouldn't do it? Because *some* cases might perform poorly? Well then, let's get rid of Text_IO because for some text files that get really large, its performance will be abysmal. And we shouldn't ought to have Unbounded_String because someone might try to fill it with a few megabytes of data and blow out the virtual memory. (We can find other examples, I'm sure. ;-) Just because something might have poor performance in a case where large amounts of data are present is not an excuse to not do something in a language. Everyone seems to say "Yeah, we ought to have some kind of container library..." but then you don't want to actually use the container library in other compiler provided packages because it might be too slow for some cases? Then why should the developer use the container library? It might be too slow for his data as well. I'd rather have a nicely integrated set of tools that all worked well with each other and if I have a case where performance demands I not use some capability, then I go for some work-around. For the rest of the cases (90%?) I didn't have to run off and roll my own to get the job done - it was already done for me. Wouldn't that be attractive to developers? MDC Warren W. Gay VE3WWG wrote: > > The OP was referring to the fact that you cannot count on the fact > that you will have a limited number of directory entries returned. > The idea works if you insist on a "reasonable" sized directory. > But this is outside of your control. > > This is much like insisting that an SQL query should always return > few enough rows, that can be held in the client program's memory. > Many programs get written without thinking ahead about this very > issue. Usually these short-sighted programs implement ok, but then > with time passing, and database growing, it is realized that > something else must be done about the original design. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ======================================================================