Re: Standard Library Interest?

["Stephane Richard" <stephane.richard@verizon.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10651 bytes --]

Sorry but my daughter accidentaly sent my last post before I finished
answering all the issues so I continue here :-).  (2 years old and she can
already send an email sheesh hehe).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:h3Bjb.17267$zw4.9742@nwrdny01.gnilink.net...
>
>
> -- 
> St�phane Richard
> "Ada World" Webmaster
> http://www.adaworld.com
>
>
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:JnAjb.8680$cT6.421284@news20.bellglobal.com...
>
> > 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 ;-)
> >
>
>
>
> > 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...
>
> *** define library?  not everyone is good at designing a library or not
> every is good at designing a set of reusable components?  In a library
such
> as CAL things should be as reusable as possible in my book.
>
> >
> > 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.
>
> *** Agreed, I think what we could do is go by the other "popular"
languages,
> the first thing would be to fill in the gap as in What do the other
language
> have that ada doesn't have?  as a first brainstorming reusable or not, but
> what makes the other languages (any and all of them) popular and give that
> to Ada.
> >
> > 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'm not sure about GRACE, haven't heard enough about the project to
say
> a word, but does it meant hat GRACE didn't have a basis for a good lbirary
> foundation?  Perhaps it did and got lost in the confusion of it's creators
> :-).  As others mentionned before if we dont have to reinvent the wheel we
> shouldn't :-).  Have you looked at my proposed hierarchy I gave elsewhere
on
> this NG?  I tried to be as General as possible but detailed enough to give
> an orentation to the library so to speak....from that tree we could see if
> anyone's existing code can fit in there and get ready to do the rest.  Of
> course that's a first draft of the hierarchy and should be worked on but
it
> is a first step :-).
>
> http://www.adaworld.com/cal/cal_library.txt
>
>
> > 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.
> >
> *** To me that seems like a good approach and I'm all for it. :-)
>
> > 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.
> >
> *** I think we all have a good common vision of what the library should
> offer that's doesn't seem to be the problem right now. the major problem
is
> starting the work without getting paid so to speak.  Like I mentionned
> elsewhere I'd be lying if I didn't wanna get paid for this effort
especially
> if it's gonna help the vendors.  I'm a developer and like all developers,
> getting paid for something is somewhat motivational :-).   But I'm not
> stopping at that for this project.  Ada needs it there's no doubt and I'm
> willing to give it :-).  so you got me as an interested and already
involved
> party :-).
>
> *** As for competition I wonder, if time wouldn't be better spent forming
> teams that could work on different parts of the library instead of
competing
> in the same one as far as acheiving the ultiamate goal goes.   Sure if
> someone looks at a stack algorithm and knows it can be done better then
fine
> do it and suggest it if it's faster/more stable, etc etc...then it gould
go
> in :-).
>
>
> > 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.
>
> *** Not likely, but not impossible especially if our library doesn't
> conflict with any packages offered by  the vendors already.  Ultimately we
> could all associate and become the first 3rd party library vendor for Ada?
> :-)
>
> > Yes, consensus seems to be the problem.

*** Indeed but that's because libraries were started without being discussed
first I think.  At least it's usually the result of developing without
discussing :-).

> >
> > > 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.

*** I second that ;-)

> >
> > 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.
> >

*** Perhaps, where are those senior members? :-).


> >
> > 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?
> >
*** Good question. :-)  only way to fix it is to reach the given consensus.
Like I said I think we all have a pretty similar vision of what the library
should have.  so perhaps that's not where the problem lies.  Getting paid
for it seems to be an issue to some Getting support from vendors or
organizations seems to be another (by support I mean someone somewhere
saying we're on teh right track and here's why.

*** What do these other lbirary projects have?  maybe that should be our
"Not To Do" list to start with? Although someof them we'd need like standard
data structures (stacks queues etc etc).  but other than that what's missing
in the other lbirary projects?

*** As I mentionned on another post, I gave a pretty good list of what I
wanted (not the hierarchy I started but another list of missing I noticed
from Ada.  perhaps we can start from that too or add that to the list of
things to do?


> > 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.

***  You sure seem to be, I am definitaly, Marin is too for a nominal fee
;-)....Robert seems to be interested too.  I talked to a few people at APIWG
and other SIG Ada Group members that like the idea (not sure how much time
they could or would invest but they do think it's a good idea :-).
> >
> > 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?
> >
*** Again here would it be competition or elaborating different parts of the
library instead?  which would be a better usage of our time? :-)

> > 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).

*** I'm all for general use, it's my foundation for participating in the
library in the first place.  That's a big chunk of what's missing in Ada,
general purpose lbiraries and components to build software that please a
more general population (business and people alike).  As in For games, maybe
tools to help build business applications, (database and reporting tighly
integrated somehow).  And various other fields of applications.

> >
> > 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.

*** I'm talking to ACT and seeing what can be done about it, I'll have to
keep you posted or maybe at that point they'll keep us all posted if all
goes well :-).

> >
> > Competition anyone? ;-)
> >
*** Got my gear ready :-).

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