Re: Standard Library Interest?

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

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
>> BTW, I finally received my printed copy of the Ada Letters last
>> week. Good work on the article.
>>
> Thanks.
> 
> Maybe I ought to author something else related to that?

If it ends up provoking some sort of "action", then
why not?

>> Apart from standards and the ARG, what about Win32Ada and FLORIST. I
>> do believe that _some_ evidence does exist. FLORIST was started outside
>> of ACT, though I don't know about the Win32Ada binding.
>>
> Except that neither one of those was some sort of "All Volunteer" effort 
> divorced from the vendors. Thus demonstrating exactly what I am hoping 
> ought to happen. Win32Ada was something that was built (I believe) By 
> Tucker Taft who was doing it for Averstar? Softech? 

That one, I am not really surprised by, due to the extent of the
work that would is involved in that. Not to mention the maintenance
of the same.

> Florist has some ACT buy-in now and maybe had some 
> connection there I'm not aware of. But it (afaik) is not "The Thing" 
> with more than ACT, so you're not portable to other vendors. If a couple 
> of other vendors were hip to it, then you'd have something there. 
> Otherwise, it is no different than had it been named GNAT.Florist.

No disagreement here really. Just don't forget however, that if
people start depending upon FLORIST to be there for all of those
Linux/UNIX projects out there, that the other vendors will at some
point say, we need a port of that as well, because customers will
be asking for it. Otherwise, I have no disagreement with your point.


>> How many competing designs where there for the Ada language, before one
>> was "accepted"?  For a container library, I think there is room for
>> several attempts before getting it "right". After all, Ada programmers
>> are much fussier about the quality and the design than in other 
>> languages. I
>> think one needs to leave room for evolution and experimentation. 
>> Eventally,
>> an emerging accepted defacto standard is bound to emerge. I think, you
>> would agree that we would like it to happen a little sooner, that's
>> all!
>>
> 
> BIG DIFFERENCE! The ultimate *CUSTOMER* was sponsoring the competition. 

You are correct about that. But I maintain that you can still have
a "bake off", without sponsorship, or even a limited sponsorship
could work (maybe some sort of prize).

> They went off and recruited designers to develop the designs. 

Open source leaves out designers?

> The 
> *customer* said "Here's what I have in mind - show me what your proposal 
> is..." 

OK, so we are back to the concensus thing.

> What you are suggesting doing is charging off without an 
> identifiable customer or an identifiable set of requirements and 

Whoa, there matie!  Remember earlier, I suggested that some guidelines
for the bake-off needed to be specified up front (aka specification), from
some sort of identifiable group of interested parties (aka "customer").
But let the project groups refine and polish the specs, with the hope
of being selected as winner.

I never promote the idea of charging off to face the windmills! Some
Open Sourced development works that way, but it hardly needs to be
that way.

 > Get an identifiable customer up
> front to say "Yes, I'm interested in getting a library" 

That has already been clearly identified.

> and b) Get from 
> them some set of desired requirements - even if its back-of-the-envelope 
> sort of stuff. 

Right. I am not saying we just form teams to come up with a
design, without some sort of guidelines. You can't have a
meaningful contest that way. ;-)  You are trying to put words
in my mouth, and they don't taste too good.

> Do that *FIRST* before wasting time building something 
> that perhaps nobody wants.

I'm not disagreeing. In fact, I think we're in agreement on
this point. You just said yourself that "even if its
back-of-the-envelope sort of stuff", which is possibly enough
to start a competition. That is exactly the idea I was promoting,
but you keep accusing me of charging off and wasting effort. ;-)

> Baby steps are fine. I just think the first and formost baby step needs 
> to be "Find out which vendors are planning to continue developing their 
> Ada compilers 

And what if the answer is that most of them are not? Are you
going to stop pushing?

What if you can't get an honest answer to that question? Are
you going to stop trying?

I think this is a reasonable thing to know, but I am just a little
skeptical that you'll get an answer, or the one you want to hear.

> and find out if they want there to be some sort of CAL 
> that they are willing to accept and play a role in developing." The rest 
> can start to fall out of there. I think vendor participation is a 
> necessary condition to starting anything.

Your point is a valid one, but let's just agree to see things
differently. The way I personally see it, the customer demand
can drive this point, without starting with the vendors.

>> I have always taken the approach of learning from doing. So I would
>> not discourage people from trying something new. Many projects may
>> end up as throw-aways in the end, but that does not mean the effort
>> is a wasted one. You seem to be worried about wasted effort(s).
> 
> Because efforts have been wasted before and I want to make a *different* 
> set of mistakes this time around. 

No disagreement here.

> If you keep trying to get through a 
> wall by running headlong into it, would you be surprised if someone says 
> "This is foolish. Why not look for a door or window before charging at 
> the wall again..." 

Well, if someone chooses to recreate a past mistake, then that
reflects on the person or team. Not the need for a solution.

> These efforts have been tried before and the evidence 
> is right out there in the Internet to look at. 

Which is why it is not necessarily a foregone conclusion that
any next effort has to be a waste. Hopefully, people/teams can
learn from what's available on the Internet. You seem to be
implying that people don't or can't learn from history. You might
even be right, but I don't quite see it this way. ;-)

> You can compare all the 
> attempts and compare all the Ada implementations and you see that the 
> attempts are not found in Ada implementations. 

I am not sure what you're saying here. Are you talking about
failed Ada container libraries here, vs where they have succeeded
else where? Please clarify.

> If you want to go that 
> route again - its your head that is going to hit the wall while I'm 
> feeling around for the doornob. ;-)

No, I have no personal plans to bang my head against the wall. I
used to do that when I was 4 years of age, until my mother finally
cured me of it by saying "Go ahead! Bang it again!"  I think I can
honestly say that I am cured for life ;-)

>>> Yes, but just recall all the other various and sundry "Open Source" /
>>> Volunteer oriented projects of any stripe that get started out there.
>>> (Should we start a list?)
>>
>> As I've pointed out earlier, a failed project is never completely
>> a failure. Someone/people have learned lessons from those undertakings,
>> even if it is just to understand their own level of commitment ;-)
> 
> Yes, and from my "failed" projects, I've learned that you need to get 
> the customer involved very early on. ;-)

No disagreement. But surely, *we* as the customer can *know* what
we want. Reaching concensus might be challenging, but that is part
of a necessary process.

> Well, I don't know what I'm leading here if anything. But if a few folks 
> representing vendors were to come to me and say "Please, Marin, with 
> your sublime wisdom and vast vision, could you somehow or other find 
> some way to devote some time to this???" I might be tempted to do so. I 
> suspect they have their own visionaries they could count on better. :-) 
> Why? You think they want to offer me a job?

I can't dismiss that possibility, but I was thinking more of
someone leading the charge with the "Let's set up a Ada Corporation
for shared software" type of thing, that you described in your article
(which I'm not articulating from memory very well here). I think
someone will have to lead the charge with a Stallman like vision, and
determination. Vision without determination is likely to fade away.

> My premise is that if the vendors wanted to drive an effort to get a 
> library, they could get one. 

The problem with this is that the vendors don't really care, unless
they see some pot of gold at the end of that rainbow. For them, I
see this as only an incremental gain, unless one looks at a long
range successful forecast.

The big payoff is in the customer's court. This is why the customer
wants it. For the vendors, it just means more to support, and a
little more to charge for (some balance between customer need and
cost has to be reached).

> If they are looking for volunteers, they 
> could find some - but probably not enough to get it to market in a 
> reasonable lenght of time or meeting requirements unless they have some 
> paid-guidance overseeing the effort. The ideal situation would be to pay 
> for the whole thing so you get exactly what you want and when you want 
> it. If you don't have that kind of cash, then get creative about how to 
> do it on a shoestring. A solution does exist. Do the vendors see it as a 
> problem they want to solve? Is there interest in taking up the challenge?
> 
> MDC

I can only really speak from a GNAT perspective, and the signs seem
encouraging from ACT. Is this enough? Will it drive the other vendors
to follow? These are tough questions to answer.

I think we are not that far apart in our thinking, but perhaps where
we place our trust is different. I prefer to take the reins approach,
where you are happy to put it in the hands of the vendors,
with a channel for input.

I could live with either approach, as long as it sees results.

But I know that your point is partly that we're all tired of
waiting for a solution.

So I guess if I was to summarize my point in response it would be
simply this: "don't dismiss the open sourced route, simply because
it has been tried, and been unfunded.  While the past is often an
indicator of what is likely, it does not necessarily predispose
it to failure." I think the last sentence is where we mostly
disagree. ;-)

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