Re: GUI was Re: why Ada is so unpopular ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Marin David Condic" <nobody@noplace.com> 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