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-22 11:35:14 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GUI was Re: why Ada is so unpopular ? Date: Thu, 22 Jan 2004 13:33:59 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <10109erl2081u35@corp.supernews.com> References: <100tkcshhdi686a@corp.supernews.com> <400FD340.3080603@noplace.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:4673 Date: 2004-01-22T13:33:59-06:00 List-Id: "Marin David Condic" wrote in message news:400FD340.3080603@noplace.com... ... > What would be wrong with a "Directories" package having a call that > would return some kind of tree data structure? One obvious answer is there is no such container in the current proposals. And the second one, as I said before, is that the time and space use of such a thing could not be predicted. It would be awful to base anything where the user is waiting for a response on such a package - it could take forever. (I have a couple of commercial programs that work this way, and they are awful to use, because you have to wait for the programs to read the whole disk - and allocate enough memory to hold it - before you can find do any operations.) > Perhaps a bunch of > smaller tree-walking type subprograms might be faster - go ahead and > provide that as well. But either you (the Ada vendor) are going to build > a tree data structure and populate it with data or I (the app developer) > am going to do it after making a bunch of more primitive calls to your > library. In the first case "you" is "1 implementation effort" and in the > second case "I" is "N implementation efforts" where N is the number of > developers needing such a capability. Seems more efficient to do it only > once. That, and it makes it darned attractive to a developer to use Ada > if most of his job is already done for him. Fine, suggest such a thing in a secondary standard. It doesn't make sense in the main standard, because its something you'd hardly ever do. (I've never ever made a tree structure in memory out of a directory walk; it's always been either recursive routines or a single level.) > Also, assuming a "Directories" package is going to build data structures > and return them, we'd likely want to have other packages operating on > exactly those data structures. (A GUI library, for example) So whatever > inefficiency might be there, you go through it only once and then have > all your other operations making use of the result. I think that's the wrong view of "Directories". It provides a set of queries into a store of some sort. Any data structures are purely programmer artifacts. And the ineffieciency you are talking about is massive. The previously mentioned backup program takes 10 minutes to scan the disk even if you want to back up a single file. I'm pretty sure we don't want to mandate that of all Ada programs! > And sometimes we just have to accept that doing some things is going to > take some time. Solving an N by M matrix where N and M are big is just > plain going to suck up a lot of CPU no matter who does it. Does that > mean that Ada shouldn't have a matrix math package? I agree to a point. If you really do need to access all of the files on the disk, it is going to take time. But the trouble with making a massive tree structure is that it makes it very easy to do something really stupid. And testing doesn't help much -- even if it works on your desktop, it might run out of memory when run on a server. I believe that this sort of thinking comes from the "everything is a container" mentality. Everything is not best modeled as a container - unless your set of containers is so large that it would be impossible for mere mortals to keep it straight. The containers that hopefully will be in the standard will be a handful of simple forms - useful for prototyping and non-critical applications, but insufficiently controlable for places where time and/or space are critical. They're not going to be appropriate for uses in other libraries. Now, we're hoping that work will continue on a series of secondary standards to provide more support for containers and whatever else. But that's clearly inappropriate for *the* standard. If you put in half of the time you spend writing these missives about how wonderful a secondary library standard would be (it must be over an hour a day based on how long it takes me to write messages here) working on one, we'd probably have one by now. :-) Randy Brukardt