Re: [Chicken-hackers] why Chicken?

[Brandon J. Van Every]

Tony Sidaway wrote:
> On 1/31/07, Brandon J. Van Every <address@hidden> wrote:
>
> > I see two approaches:
> >
> > - a recruitment strategy that attracts massively more open source
> > developers to Chicken.  So that we get out of the tens and into the
> > hundreds of developers.  If I had an entire team working on build
> > issues, we wouldn't have any build problems, and nobody would be doing a
> > ton of boring build work.
> >
> > - a brilliant technology that automates binding work.
>
> Failing the latter, I don't think the former is likely to happen until
> we have basic pre-packaged bindings for many of the things that
> developers want to do.

"Many" implies an utter lack of focus.  If we build everything, they 
will come.  Heh, not!

Is there something more specific you think developers should be doing 
with Chicken?  Something that can be Chicken's "killer app" or "killer 
problem domain?"

I know that for me, this is supposed to be games.  But I just can't get 
there when I'm being distracted by build issues all the time.  I'm going 
to have to learn to say "no," unless it's either really easy or really 
important.  Actually, if it's really easy, someone else should probably 
be doing it.  I would amend that to read, "really easy for me, but 
difficult for others."

> Writing bindings is easy for small scale tasks such as wrapping a
> single medium sized C library.  For anything larger, it's non-trivial
> even with the foreign code interface and/or SWIG.  We should encourage
> all regular chicken developers to release eggs for the common binding
> tasks (we've already had huge success but there is always more to do).

What does "encouragement" mean?  I don't think expressing a desire on a 
mailing list means anything to anyone.  People have to actually do 
stuff.  Mostly they have to organize themselves.  Perhaps there's some 
way we could help them organize themselves?  I had an idea about a job 
queue a few months ago.  But there has to be a cadre of people who 
actually want to take things on.  We can make wishlists until we're blue 
in the face; doesn't mean anyone's gonna do them.  I suspect that 
getting people excited, and getting people to do real work, needs more 
than just a queue of TODOs.

> On the core language, it might be nice to have constructs capable of
> handling the most common instances of C variable length argument
> lists.  I'm aware that there are some fundamental C implementation
> dependencies here but if SWIG can do it (badly) it ought to be
> possible to encapsulate the basics in a manner flexible enough to be
> used in hand coding.

I'm not seeing how this is strategically important.  It would be nice to 
have, but it sounds like an incremental feature request, not a core 
business strategy.  We should use the bug tracker for this sort of 
feature request.  That's what the CMake project does. 


Cheers,
Brandon Van Every