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

["Warren W. Gay VE3WWG" <warren@ve3wwg.tk>]

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