Re: Standard Library Interest?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
>> IFF you get this kind of answer from some, most or all of the vendors,
>> then I would agree that you have a "point". But IMHO, this is unlikely
>> first of all (its not in their interest to go against what the user
>> base wants), and certainly not a foregone conclusion. Note the "FF"
>> in "IFF".
>>
> Yeah, but AFAIK, they have not said what they *do* want and (assuming 
> they are the initial "customers" you're trying to satisfy) charging off 
> to build something on pure speculation without knowing what the customer 
> wants is a most profound - if not outright sinful - waste of time.

Agreed, but *you* are a customer, and *I* am a customer in the
open sourced sense. *We* know what we *want*, and certainly should
be in some position to understand what *others* like *us* want.

That says to me, that we are favourably positioned for some involvement
here ;-)

> Like I've observed elsewhere - we have libraries out there already. Any 
> one of them could be adopted as the basis on which to build. 

Yes and no. Not everyone is good at designing "libraries" for
general use, and so I would suggest that in a library sense,
some *are* more suitable for others. This of course, depends
upon agreed upon criteria...

> This has 
> not happened. There must be *something* about that path that the vendors 
> are not terribly fond of. 

Yes, agreed. If comp.lang.ada history is any indication, it
seems to be a general lack of agreement! Some want:

  - for embedded use (no dynamic memory allocation)
  - SPARK like qualities
  - C++ like qualities/idioms
  - easy to use (few instantiations of generics)
  - maximum flexibility (with more use of generics,
    but harder to use)

and there are probably more directions. I would add that there needs
to be a more "general purpose computing" focus, to get Ada into
more mainstream use.

But if *we* can't *agree* about what we *want*, then the rest
is a dead end.  My memory is foggy about the GRACE components
effort, but what I recall of it was a wide range of opinions
of what it should and shouldn't be.

I don't have any silver bullet for this problem, but one
suggestion might be to assemble a few respected and interested
parties (individuals that is), and build concensous amongst
themselves. Let them go away and build a spec, a pilot maybe,
and come out of it with a "like it or lump it" approach,
allowing for tweaks.

If there is enough other interested parties, then perhaps a
"competition" of sorts between different teams could be
arranged (I want to be on the green team ;-). Then pick a
winner, and tweak and live with that winner.

But IMHO, the biggest stumbling block here has always been
about building a common vision.

> So before building Yet Another Ada Library and 
> hoping to get all the Booch and Charles and Etc., users to switch to 
> that and show the vendors that they must get on board because all their 
> customers are doing so, why not just ask the vendors what they'd want to 
> see done first?

If you can get all vendors to ship the same thing, no matter
what it was, you can be sure people will use it. After all, the
GNAT packages get used that way. BUT, I don't think this
is likely to happen.

>> What drives the vendors, is what the "users want". Get them using
>> your stuff. Get them wanting more of your stuff. IOW, get the users
>> hooked first (a very time honoured principle). The vendors will
>> fall in line from there. Demand usually drives business. Only in
>> creative things like the Segway (sp?) where people didn't know they
>> wanted one, does it work the other way. But I don't think the
>> vendors are going to have any kind of a surprise for anyone on
>> this front. ;-)
> 
> Yes. Absolutely. The vendors will be driven by customer demand. But 
> right now, there are a dozen or so libraries out there and absolutely NO 
> consensus on which one should be adopted as "The Thing". 

Yes, consensus seems to be the problem.

> I think 
> customers if surveyed, would indicate that they would want *some* kind 
> of library. 

That much seems to be agreed on here in comp.lang.ada.

> They already seem to like getting things like Ada.Strings... 
> and Ada.Numerics... But perhaps they can't agree on which of several 
> existing ones to adopt. Would you propose throwing Yet Another Ada 
> Library into that fray to further divide the pie? If we could agree to 
> adopt one of the existing ones as the basis & start building from there, 
> fine. Except it hasn't happened. If none of these are "Good Enough" then 
> perhaps we can build one that *is* going to meet with acceptance. But 
> who's acceptance and what are their criteria? That's what the vendors 
> could decide and settle.

I like the idea of small teams that are capable of consensus, and
the idea that a competition with a winning design should be
adopted. Where this seems to fall down, is that the very people
that should be involved, do not have the time to allocate to this.

So then, perhaps we should be more open minded to what other
eager teams might be able to produce, with perhaps a senior
member to help guide their efforts in an advisory fashion.

> This whole thing is a vicious circle. The vendors are waiting for some 
> clear mandate from their customers. The customers are waiting to see 
> which library will start shipping with their favorite compiler before 
> going through the pain of switching out whatever they're using now in 
> favor of something else. The standards bodies are waiting for both of 
> these groups to settle on something so they can put their Imprimatur on 
> it. So who's going to be the first one to get the ball rolling?

I agree, but I prefer to focus on the reason why nothing is
happening. Lack of consensus, as you've said yourself. So let's
attack that. How do we fix that?

Smaller groups have a greater chance at consensus. But one group
may not achieve the best result.

Take the "Ada approach", and allow teams to submit competing
designs.

The question is, do we have enough interest to develop more than
one team?  This to me is the most doubtful factor.

> I just can't see starting another volunteer effort to charge off and 
> build some new library when we have had plenty of that already and it 
> hasn't worked. 

Any competition, does not _have_ to start from scratch. Let's
bring on a competiton where new and existing stuff is worked
and re-worked in competition.

You'll need to keep the final panel of judges small enough, or
some other democratic way of selecting a winner (voting?) As
long as the rules are clearly stated up front, and the parameters
properly planned, any "volunteer effort charging off" can
spur good results (if only by competition).

The real issue is consensus and enthusiasm. I think the former can
be achieved, but can we get enough participants to push the
competition forwared?

> Someone with some "clout" has to drive the development 
> and I see that as being the vendors. 

We can give "clout" to anyone, any "body" for judging or
voting purposes. The objective is to get general buy in,
and this may be a problem, because I suspect most Ada
users are most interested in embedded processing rather
than for general purpose use (but I would be happy to be
wrong about that).

If we have a clear winner at the end, then hopefully we
then *know* what we want, and get vendor interest. We
might also have a working implementation in GPL/PD form.

> If you could get even *ONE* vendor 
> to say "All right, we'll go down this path and start shipping this 
> library if you guys go off and build something that meets these 
> guidelines...." then it stands a chance of getting off of bottom dead 
> center. But without even ONE vendor standing up and saying "This is what 
> I'd like to see built....", I don't think its going to get very far.
> 
> MDC

I think getting ONE vendor is achievable, and certainly a baby-step.

Competition anyone? ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg