This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: I resign as Guile maintainer
- To: forcer <forcer at mindless dot com>
- Subject: Re: I resign as Guile maintainer
- From: Doug Evans <dje at transmeta dot com>
- Date: Thu, 2 Dec 1999 09:33:12 -0800 (PST)
- Cc: Marius Vollmer <mvo at zagadka dot ping dot de>, guile at sourceware dot cygnus dot com
- References: <199912010422.XAA01070@savonarola.red-bean.com><87u2m2s22n.fsf@zagadka.ping.de><hhn1rt5ml7.fsf@forcix.burse.uni-hamburg.de>
Thank you!
If enough people who agree with this step forward (I have felt so for
a long time (~3 years) but I must confess my own cowardice in the
matter), I think that would be a big step forward.
I agree that SCM is slick, but it is inappropriate for the task at
hand (IMHO of course).
forcer writes:
> [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.
There's also too big a relearning curve after one returns to it after
a bit of absence ... if maintaining Guile isn't your day job,
it's a struggle ... (Jim?).
> 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"))