Re: IBM Acquires Rational Ada

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

Exactly, 100% the point. Ada seems to be so busy coming up with a "perfect"
answer that it misses the point - even a bad answer is better than *no*
answer. If the Ada community was willing to gather under the auspices of
SIGAda or some other organ and declare that some library of containers
(existing, or to be developed) was "The Conventional Answer" and started
delivering Ada with it, then Ada would have containers by now and not be
lagging behind C++ in that respect. Regularly working on that library to
extend and enhance it would bring Ada ahead of C++ in that regard. The fact
that the best we seem to be able to do with respect to libraries is to raise
the issue as an "Ada0x" standards issue is symptomatic of why Ada has a
problem catching on with the masses. A useful, leverage building capability
is going to take *years* to get in place and even then will probably only
address some small fraction of the needs based on least-common-denominator
factors. Why can't we find a mechanism to get things like this into
"Conventional Ada" more quickly?

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Hyman Rosen <hyrosen@mail.com> wrote in message
news:1039712678.466533@master.nyc.kbcfp.com...
>
> Here's what Scott Meyers has to say in his preface to _Effective STL_:
>
<http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407
-4011-B7D3-0C924DFA675D}&selectDescTypeId={0BBA7A1C-E080-49A0-B103-E1BE9F7C7
092}&st={75A0BC87-B9B4-435A-86E0-36F0AC8E0923}&session_id={4C1AEA22-4C0C-4D6
2-8DB2-5552A4AFA3C9}>
>
>      Then I began to notice something that took me by surprise. Despite
>      the portability problems, despite the dismal documentation, despite
>      the compiler diagnostics resembling transmission line noise, many
>      of my consulting clients were using the STL anyway. Furthermore,
>      they weren't just playing with it, they were using it in production
>      code! That was a revelation. I knew that the STL featured an elegant
>      design, but any library where programmers are willing to endure
>      portability headaches, poor documentation, and incomprehensible error
>      messages has a lot more going for it than just good design. For an
>      increasingly large number of professional programmers, I realized,
>      even a bad implementation of the STL was preferable to no
implementation
>      at all.
>