Re: guile: going the way of DEATH

[Jonathan Shore <jshore@lehman.com>]

I'm not going to add anything to this discussion other than to say that I
 agree completely with the opinions below.  We've done alot of TCL work
here in the past simply because there hasn't been a better alternative in
terms of packaging, stability, and embeddability.  I've been on the fence
for a while hoping to be able to use GUILE once a well packaged / tight
release is available.

I would encourage the GUILE development community to take note.  I would
hope that this development effort can transform towards being more of a
product rather than an academic excercise.

Alexander L. Belikoff wrote:

> 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
>
>