Re: I resign as Guile maintainer

[forcer <forcer at mindless dot com>]

[i cut off most of the extra recipients - this mail is more
important to the guile list than to anyone else]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> [...]
> it is a clear signal that something is wrong with
> the Guile project and that something needs to happen.
>
[...] 
>
> Now, what's going to happen with Guile?  Is it dead?  Or merely ill?
> Is its illness infectious?
> 
> I don't know.  I'm kind of emotionally attached to Guile, because it
> is the project that was my ticket into the Free Software community.  I
> still have the letter from the FSF pinned to my wall that I got when
> signing over my copyrights.  So, it's hard for me to just let Guile
> die.

Same for me - i'm just hoping for a chance to commit some bigger
change so a copyright signover would be feasable :]

> I never really resonated with other Scheme implementations either.  I
> slowly began to think that SCM was a good choice as the basis for rms'
> goals of a universal extension language, although I didn't understand
> it in the beginning.  Its design decisions fit well with being a
> library in a C world, and yet it is efficient and makes no
> functionality compromises.  So, I don't think Guile is fundamentally
> technically flawed.
> 
> In my opinion what's wrong with Guile is that it develops more and
> more into a patchwork of half working concepts.

That's the one big problem. And it's not a surprising one, given
such comments as "we need a maintainer that's not afraid of eval"
or "once i figured out the internals of guile".

Scheme is a very clean and simple language, and it shouldn't be
such a big problem writing an interpreter for it that's halfway
easy to understand if you sit down for a few hours and read the
source. It's one of the paramount objectives in current software
projects - the maintainability. And in my humble opinion, Guile
in it's current incarnation fails exactly there.

The evaluator - as astonishing as it is, great work Aubrey - is
*very* difficult to understand, even if you know C quite well and
sit down for a week. The ifdef's etc. add even more difficulties
there, though they are "justified" in eval.c.

The bit-tags are three-layered, if i understood correctly, and
not too easy to understand either. The existence of macros to
test for types helps a bit, but if you have to check for some
bug, it's not *that* easy.

And as Marius pointed out correctly, Guile is a patchwork of
half working concepts. It lacks a basic design - it lacks the
same thing that made Perl and Tcl the big blobs they are
today. Guile has the advantage to be built ontop of a very clean
and very nice language, but it slowly grows into a blob itself,
because people demand so, and don't think of a good basic concept
first.

If Guile is going to be the "one" extension language, it should
have very clean, very simple internals. This includes a very
clean, very simple facility to extend it. Guile has alot of good
ideas, but i think it's partly hampered by it's difficult, non
thought-through internals. 

The way it is currently, i won't be surprised if Guile will be
completely rewritten (from scratch, probably) by next year.

- The numerical tower will be replaced.
- The environments will be replaced.
- The module system will be replaced.
- The garbage collector will be replaced.
- The reader will be replaced.
- We'll have two kinds of heaps.
- The evaluator maybe might be replaced (there have been long
  discussions of replacing it by a bytecode compile-evaluator
  pair).
- Most of the stuff in the guile core is slowly being put out into
  modules.

Since all those - very good - ideas will be implemented and
integrated independently, Guile will retain some legacy code, and
eventually will be rewritten.

I hope you didn't mind my rambling here, but i had to say all
this, because it was nagging on me for some time now.
	- Jorgen aka forcer

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))