On 1/31/07, Brandon J. Van Every <[EMAIL PROTECTED]> 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? _______________________________________________ Chicken-hackers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-hackers
