Re: Future with Ada

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

"Pat Rogers" <progers@classwide.com> wrote in message
news:YxvS7.2239$_h.1737012240@newssvr12.news.prodigy.com...
> > >
> > But I don't recall that there were large number of folks calling Thomas
> > Edison on the phone and asking for him to invent the light bulb. Nor did
> > people Fax Henry Ford pictures of the car they wanted with a suggested
> name
> > of "Model T". :-)
>
> :-)  On the other hand, there weren't competing auto makers, lightbulb
> manufacturers, etc. available.
>
But that ought to be a clue that "The Market" is in desire of some specific
kinds of things. If C++ provides the STL and developers like it and use it,
that ought to suggest that a compiler that comes with something similar
would be of desire to the users of Ada. If Java comes with class libraries
for building GUI apps, that should  be a signal that users would want
something similar from Ada. Customers don't always call you on the phone and
tell you they want a specific capability. Sometimes they "vote with their
feet" and buy some other product because it fits their needs better. (Can
you hear a customer saying "Ada's O.K. for this kind of thing but when we
want to build Web/GUI apps, we just switch to Java..."?)

Granted, you can't do everything and you can't be all things to all people.
Hence you have to try to get some signals as to what is going to be the most
profitable way of allocating your resources. But I think with the "Data
Structures" case, the problem is that you might have - say - 50 ways of
doing essentially the same thing and 100 opinions about which is the best
and why. Specifically *because* there's such a shortage of consensus,
(except consensus that having one would be A Good Thing) getting something
imposed from the outside (or at least some direction/guidance) would likely
be a big push for success.

I like the stuff that has been come up with in the latest discussion. I
think that Ted's strawman would be a good compromise of all the competing
goals and objectives. If we had that much (and Maps) riding along with most
compilers (and a promise of possibly more things as experience suggests)
we'd have a richer language.


>
> > Sometimes businesses come up with something great and new and go
> > out and educate their customers as to why they would want to have it.
> > Waiting for a groundswell of demand from the customer base for some
> > particular container library is, IMHO, just about guaranteed to result
in
> No
> > Standard Ada Component Library(tm).
>
> I confess I don't see why not, unless you mean there would be no
> groundswell, in which case I would have to agree.  Hence my original
> proposal -- let's start the groundswell!
>
>
Well, because what you have is a single groundswell that says "A library of
components is a good thing" and then you have a thousand mini-groundswells
that say "And in the library that *I* want, there should be X and Y and..."
So if a vendor is going to wait for - say - 50 paying customers to all stand
up and unanimously say "Put Library N On Your Distribution" it might be a
cold day in Florida before it happens. :-) Whereas, if the vendors were
saying "We agree that if a library is going to be distributed and supported,
it ought to be: <Insert your requirements or favorite library here>" it
might start coalescing some of the demand around something in particular.

So while I understand the direction you are proposing and I agree that it
would be expedient & would get results, I guess I have doubts that the
consensus will congeal unless the vendors were involved in setting the
direction. That's why in some ways what is going on with the strawman
discussed elsewhere is a positive step. In the abscence of any other
direction, people are coming together and negotiating something they can
mutually live with. That might produce a library that has enough "buy in"
that there might actually be some demand for one specific existing library.

Just my thinking on the subject.....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/