Re: guile: going the way of DEATH

[mcmanus@IDT.NET (Russell D. McManus)]

abel@bfr.co.il (Alexander L. Belikoff) writes:

> Hello everybody,

Yes, hello.

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

You have succeeded in offending me.  Is it your intention to offend
people and somehow jolt them out of their supposed fantasy world?  I
think you underestimate the people on this list.

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

Yes, Guile needs to be split up.  I encourage you to post some patches
that do that, or to propose to the list how this can be done (I'm
serious).

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

It sounds to me like Tcl works for you.  If Tcl meets your needs, I
encourage you to use it.  If you want to use Guile, you may have to
carry some water yourself.

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

This is a factual error.  Mark Galassi took considerable care when
designing the gh_ API, which is the application writer's C level
interface to Guile.  This interface has changed very little since it
was defined.  And IMHO the gh_ interface is logical.  Please share a
contradictory example.

And as for the Scheme API, guile follows RnRS with only (very) minor
changes, and with a number of useful additions.

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

Yes, I would like to see STk's elegant Scheme interface to Tk
ported to Guile.  I encourage you to work with Erick Gallesio
to get this going.

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

You seem to know exactly what guile needs, but simultaneously, you
want the Guile developers to put out more frequent releases so they
can get to the *real* priorities.  These two points seem contradictory
to me.

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

Could you share an example that demonstrates the decline of Guile?  I
propose a metric: posts per day on the Guile list.  I assert that the
number of people using Guile is positively correlated to the number of
posts per day.  I haven't run the numbers, but if you look at the last
year, I bet you'll find that more people are using Guile today than
one year ago.

I'm going to stop here before I get exhausted.  You see, most of the
people on this list agree with a lot of what you say.  But you must
understand that people are working on these things, and that rather
than complain about things people know need to be fixed, you could
spend your time fixing bugs, or maybe more importantly, bringing the
manual up to date.

-russ