guile: going the way of DEATH

[abel@bfr.co.il (Alexander L. Belikoff)]

Hello everybody,

What I'm gonna say will probably offend many of you. But my point is
that it is better to discuss it now, before Guile is completely dead.

John Osterhout's Tcl was designed with several goals in mind. So far,
Guile hasn't addressed any of them:

1. Tcl is a *small* library, which is critical for an extension
   language: libtcl.so is ~400K. Guile is very big - current version
   of libguile.so is more than 1Mb - almost three times as big as
   libtcl.

2. Tcl was written from scratch and consisted of a small number of
   clean interfaces, defining the language and a small C API for
   extensions. This was enough (and still is). All other Tcl-related
   stuff is just a bunch of optional extensions.

   On the opposite, Guile was initially based on one implementation of
   Scheme (SCM) with some pieces borrowed from another one. This led
   to a horrible mix of interfaces and interdependencies in the code.
   Also, nobody even tried to define both Scheme and C API - they are
   still in flux and dirty, lacking logical order.

3. Tcl has a very elegant GUI toolkit, which is not just a set of
   X11 or Motif bindings.

4. Finally, Tcl was actively promoted for applications with frequent
   bugfixes and releases.

   Guile in this sense, is doing the other way: the only 'official'
   release is the brain-dead 1.2 (dunno about that one, but 1.0 took
   about 8 (eight) seconds to load a 'guile' program on my old 486),
   which is about 2 years old. On the other hand, the Red Bean folks
   are quetly developing Guile at their site, making snapshots
   available. However, snapshots are different from releases - they
   don't give people a comfortable feeling of program's getting mature
   and they don't give developers an incentive to make a program ready
   for general public: one can just keep producing snapshots forever.
   The snapshots are used just by a bunch of enthusiasts, thus lacking
   wider feedback, so the developers may not get an idea of what
   most people really need, what the *real* priorities must be!

All the above, in my opinion, is steadily leading us to the death of
Guile. People will forget about it long before the next release and
the only thing they will remeber would be the "Guile vs Tcl" flamewar,
which led to nothing.

Still, I think we have a chance. We must learn a number of lessons and
if we do that, we'll be able to revive the project and to make Guile a
standard and reliable GNU extension language.

In my opinion, the following must be immediately done about Guile:

1. Interfaces must be defined and frozen. I mean both Scheme and C
   ones. This is the most important thing now. The users (people
   developing using Guile) must have a clean set of API and be sure
   they won't change from release to release (at least,
   significantly). 

   OTOH, nobody cares what really is inside Guile - whether it is SCM
   or VSCM, or SIOD - this must be *completely hidden* from a user.
   Same goes for garbage collection engine.

   Once we define and freeze the API, we may produce a Guile reference
   manual which won't change in the future.


2. Small is not just good. It is vital for an extension language. The
   API must be *small*. Let's learn from Tcl. I'd suggest the
   following set of API:

   Scheme: R4RS, *basic* process I/O, formatted I/O, symbol table
   access, regular expressions, *very basic* OS interface (directory
   reads, system(), exec) - I'm literally going through the Tcl
   reference manual

   C: interpreter management, file loading, string code
   interpretation, module creation API - modules must be .so files to
   be dynamically loaded. This will give us the extensions development
   framework.

   And that's basically it. This would be THE Guile and it would be a
   perfect base for further extensions development. People would be
   able to provide extensions without cluttering Guile itself. After
   all, not everybody needs SCSH compatibility, let alone the
   notorious Ice - 'Guile Operating System'.

   Until THE Guile is ready, I'd suggest temporary stopping of the
   development of some other ambitious Guile-related projects: SCSH
   compatibility and the compiler.

   In the meantime, we may adapt the existing version of Guile to THE
   Guile. But in the future, we may consider rewriting the Guile
   interpreter from scratch to get away from SCM legacy.


3. Once it is done, several extensions must be developed (as .so
   modules):

   POSIX O/S services - to allow those developing OS utilities in
   Guile greater control.

   Low level socket interface - for the same reason.

   A GUI module. I am not sure it should be Tk. After all, Tk still
   contains a lot of Tcl legacy bindings, which would mess the things
   up. I'd rather go for some C GUI toolkit and would make Guile
   high-level bindings for it, learning from Tcl/Tk success. The
   bindings must be really high level - not just the mapping to C API.

   So far, the most obvious and attractive choice is GTK. It is stable
   enough, it is THE GNU GUI toolkit, and it is supposed to be a GUI
   of forthcoming GNU Desktop - Gnome.


4. *Official* releases must be fairly frequent - every 3-4 months.
   This would grant wide feedback, which, in turn, would grant, we are
   working on right prioroties. Guile advertising must be somehow
   aggressive - it must be emphasized that Guile IS a standard GNU
   extension language, and it IS ready for general use. People must be
   shown, how easy it is to write  stuff in Guile, how it simplifies
   things compared to C/GTK+

I'd like to hear your comments. In particular, I'd like to hear from
Guile development team. What I propose requires significant changes in
their practices, so I'd like to know, what they think about it...

Regards,

-- 
Alexander L. Belikoff
Bloomberg L.P. / BFM Financial Research Ltd.
abel@bfr.co.il