Re: Grace and Maps (was Re: Development process in the Ada community)

[Michael Erdmann <Michael.Erdmann@snafu.de>]

Marin David Condic wrote:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0204190529.559a47ae@posting.google.com...
> 
>>I've actually been thinking along similar lines. What I'm wondering is
>>if we should keep the list package as "Lists.Unbounded", or if we
>>should just bag the whole bounded/unbounded issue and make it "Lists".
>>
>>
>>
> O.K. Let's cash in our reality checks and see if they bounce. Would it be
> fair to say that *most* Ada developers and applications are some flavor of
> Windows/Unix with no realtime requirement beyond "Don't run so slow as to
> annoy the user..."? If that's the case, then we're looking at virtual memory
> machines that probably run very fast and hence, having fixed or bounded
> lists doesn't seem like it would be very important.
> 
> If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
> really good start. If at a later point in time there was some kind of
> groundswell indicating that there really was a need for bounded versions,
> why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
> I can think of is that it isn't consistent with Ada.Strings.
> 
> An interesting observation: When I write most apps for a PC in Ada, I tend
> to use the standard, fixed strings only at the points where Ada defined
> functions require them. (Stuff like Text_IO) The rest of the time, I just go
> to Unbounded because from a programming perspective, its just so much more
> convenient. In most instances, whatever performance penalties might exist
> for it are so far below the noise floor that they are invisible. Is this
> experience unique to me or would most Ada programmers report similar
> experience? If Ada were to totally abandon fixed and bounded strings (in the
> sense that they were never there - not from any sort of compatibility
> perspective), would you notice or care most of the time? (Presuming you
> could get them via some add-on package of your own creation if you ever
> really needed them?)

I have to agree on your observation, convenience is very important. In
earlier days there was a lot of disussion about the yield of high level
languages compared with low level methods like assembler. The discusion
was around the same issue, performance, realtime behaviour, memory usage
etc....

So i agree, i would be a good start which is proably covering most of
our requirements.

Without trying it, we will never fail, which means we will continue
discussing without learning anything by testing the aproach in
real life development scenarios.

Regards
     M.Erdmann