chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Industrial use of Chicken?


From: Category 5
Subject: Re: [Chicken-users] Industrial use of Chicken?
Date: Wed, 31 Mar 2004 17:28:41 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)

Hi Dominique!

The first thing I'll say is that I have not yet used Chicken as a core
part of any commercial-grade or high-availability type of application.
I am very sensitive to the requirements of these domains, though,
particularly those that obtain in the communications industry.  I hope
my comments will be of some use despite the caveat.

Chicken is the closest thing I've seen to a truly practical
industrial-grade Scheme that integrates very well into the Unix
environment.  The only other that comes to mind is Gambit, which also
seems to be superb, but I can't say much about it as I wasn't able to
get it to build on my development platform.

Chicken has some critical features that support my view:

- Compiling Scheme programs to native binaries with Chicken is as easy
  as compiling C with gcc (easier, actually).

- Building, linking with and dynamically loading shared objects is
  simplicity itself - this is crucial, and Chicken does it very
  cleanly.

- Chicken has an incredibly good FFI for building interfaces to existing
  C code.  It is straightforward (mostly) and very powerful.

- Chicken has strong optimisation and solid performance.  The GC in
  particular performs very well.

- Chicken is, in my experience, extremely stable in terms of the core
  operation of the runtime.  The only times I've ever seen it crash on
  real code were when I was making heavy use of low-level C and FFI
  calls, and these cases were all my own fault as far as I recall.  The
  compiler declarations also allow you to make trade-offs between safety
  and performance.

- Chicken has profiling and debugging support.  This last appeared very
  recently, but it's already extremely helpful and is expected to get
  more sophisticated.  Good debugging support is not easy to come by in
  the Scheme world.

- Chicken is highly portable and plays well with all types of Unix I've
  tested it with (a lot, 32- and 64-bit).

- Chicken is very actively developed and supported.  Felix is
  astonishingly responsive to questions and requests.  Bugs have a
  tendency to get fixed and features added before you can finish
  asking.  =)

On the other side of the ledger, the following things can make using
Chicken in such an environment tricky depending on the situation:

- No bignums.  This can hurt a lot depending on what you're doing.  I
  understand a GMP bolt-on is available but haven't tried to use it.

- Slower startup times if you need highlevel macros.

- Limited number of arguments to procedures - be careful with apply.

- Because Chicken is so actively developed, it changes very rapidly.
  Releases often include significant changes, though rarely ones that
  would break existing code now.  This is probably the biggest hurdle to
  real industrial use - the fowl is young still, and something of a
  moving target.

How the balance falls for you will again depend on exactly what you're
doing and what your requirements are.  I think Chicken would be a
fantastic choice for 'avant garde' projects but I would be wary of
using it to, e.g., implement an embedded OS for a carrier-class voice
switch (at the moment - I've been pushing gently to fill in the gaps
that separate it from such demanding domains, thinking about making it
suitable for embedded applications, realtime GC, etc.).

If what you're trying to do is more on the order of the latter and
Chicken's relative youth worries you, you may be better off looking at
Common Lisp.  CL is definitely 'industrial grade' and has many, many
such existing applications out there and a number of solid, venerable
and actively-supported implementations.  It can also be optimised to the
point where it outperforms C, if you need that.

It's not nearly as Unix-hip and comes with a lot of cruft, though.  =)

-- 





reply via email to

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