chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] why Chicken?


From: Tony Sidaway
Subject: Re: [Chicken-hackers] why Chicken?
Date: Wed, 31 Jan 2007 17:53:35 +0000

On 1/31/07, Brandon J. Van Every <address@hidden> wrote:

Some of the answers to my plight are inevitably personal.  I'm not
asking anyone to wave a magic wand and make me a better programmer, or a
better game developer, or drop cash from the sky, etc.

What I'm looking for in others, however, is commentary on the strategic
road map of Chicken.  What are we accomplishing as a community?  What
are we not?  What could we be?

What does Chicken do that other languages don't?  What could it do?


Hi Brandon.  First, thanks for all the help on building Chicken in the
past couple of weeks.  I've found your advice on use of CMake and
out-of-directory builds invaluable.

Rather than muse on the future of Chicken as a whole, I think I'll
suggest one single direction that I think would bring the most
benefits to the usefulness of Chicken.

Chicken is pretty stable and comes in a small and maintainable source
package.  It lacks the visibility, and consequently the large
community, that languages such Perl and Python have built up.  At the
same time it has the power to compete with them and many other
languages, and (with other Schemes) excels them all in producing
maintainable code in a reasonable timescale.  And being a hybrid it
lends itself easily to the combination of low and high level
programming that characterizes many real world applications.

For these reasons, Chicken isn't lacking attractiveness to excellent
software developers.  What (apart from its relative obscurity) stops
them using it?  It isn't the brackets, although they may drive away
novices and intermediate programmers who have nothing to gain by the
effort of learning a new language unless it provides them with access
to a huge wealth of library software that would otherwise be out of
reach.  No, Chicken is hard work.  It's pitched at the Lowest Common
Denominator, Posix, and if you want to do anything useful the first
thing you must do is produce a set of language bindings.  While this
isn't too difficult in Chicken, it is time consuming work and it's the
sort of thing developers expect to come as part of the package with
any modern language.

There should be a set of bindings for various native OS features.
Staying in the Posix ghetto was an attractive option ten years ago
when the most widely used version of Windows was little more than a
toy, but if Chicken is to be useful for producing widely-used software
that exploits the full capability of modern systems it must provide
the kinds of interfaces that developers need, and that means more
bindings to native features, in particular native Windows features and
CLI (.Net) features.  If these were provided in eggs the clean
simplicity of the core language implementation would not be affected.
On the UNIX side, a similar lack of Gtk/Gnome bindings and the like
makes Chicken programming quite hard work.  Similarly they need not
concern Chicken's core.

On .Net, I imagine that it may be possible to produce code that can
handle managed CLI objects by compiling the C code using the managed
C++ compiler.  It would be nice to see Chicken usable as a .Net
language.  However the unusual stack management of Chicken may make
this quite difficult or impossible to achieve.  Felix?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]