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 10:04:41 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!shaw.ca!sjc70.webusenet.com!news.webusenet.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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> <401122E6.4010405@noplace.com> In-Reply-To: <401122E6.4010405@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 23 Jan 2004 12:50:24 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1074880173 198.96.223.163 (Fri, 23 Jan 2004 12:49:33 EST) NNTP-Posting-Date: Fri, 23 Jan 2004 12:49:33 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:4734 Date: 2004-01-23T12:50:24-05:00 List-Id: Marin David Condic wrote: > 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? Here you have full control over N and M. In the file and directory case, you are not (unless your specific application does some restrictive work to insure this). > 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. ;-) Text_IO does things in "parts". I don't know of any Text_IO feature that loads the entire text file at once (this would be in the same problem domain, where the entire file might be resource constrained). I will grant you that the types chosen to deal with file position (index) also set limits, but the point is that you are working with text files in chunks (lines, characters or blocks). In the same way, directory operations are usually in pieces of one file/directory name at a time (though nothing prevents an API of processing the same in blocks of names). > 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. Agreed, but the examples you cite, don't wash as far as I can see. If you want to load directory entries in managed chunks into a container, then this is a fully controlled operation (no "denial of service" consequence is possible). As someone else has pointed out in this group, when speaking of a GET operation that returns an unlimited length string, there is a danger that the operation will fall over when you didn't want it to (an attempt to read an extremely long line from the network or something). Worse than that, some O/Ss do not respond too well when all VM is consumed by a process, taking down the whole host. I know from experience that earlier Linux kernels had this problem (and may still be so), and I am sure there are several commercial kernels that also do not handle this well either (perhaps a good one to do on SCO boxes these days ;-) > 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 am not against it on performance grounds. For my money, performance is still growing quickly, and what some spend too much time fussing about today, becomes a no-brainer tomorrow (aside from embedded systems where budgets are different). > 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 No argument there, when it makes sense to use containers. But I do believe that you must hold the "reins" of them horses ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk