This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Translation for extension is a bad idea
- To: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Subject: Re: Translation for extension is a bad idea
- From: Jonathan Bartlett <johnnyb at wolfram dot com>
- Date: Thu, 13 Jul 2000 06:16:28 -0500 (CDT)
- cc: Jonathan Bartlett <johnnyb at scully dot wolfram dot com>, =?X-UNKNOWN?Q?J=FCrgen_A=2E_Erhard?= <jae at ilk dot de>, guile at sourceware dot cygnus dot com, John Harper <john at dcs dot warwick dot ac dot uk>
From the FAQ (http://tizer.dcs.warwick.ac.uk:8080/sawfish/FAQ):
15. Why don't you use GUILE?
Mainly because I'm lazy; I had already written rep, and therefore
understood it completely, whereas I have never used GUILE. Also, rep has
some features not available in GUILE (byte-code compilation, autoloading,
built-in event loop, ...)
Also, I know from experience that one reason I decided to go for sawfish
over SCWM is that SCWM requires that big constraints library. I was
wanting a somewhat minimal window manager, and I just couldn't imagine
SCWM being that thin with that large constraints library attached.
Jon
On 13 Jul 2000, Greg J. Badros wrote:
> Jonathan Bartlett <johnnyb@wolfram.com> writes:
>
> <snip>
>
> > > Han-Wen> It's too bad that the space for window managers has
> > > Han-Wen> already been taken from GUILE, but maybe we can show the
> > > Han-Wen> power of GUILE with another application. That will
> > > Han-Wen> accomplish much more than any kind of translator will
> > > Han-Wen> ever do.
> > >
> > > Actually, there's SCWM (you're aware of that, I assume). Which makes
> > > a bad point for Guile when compared to Sawfish (but that may or may
> > > not be the fault of Guile).
> >
> > Actually the author of Sawfish has mentioned going over to Guile. He had
> > a few problems with it (I can't remember them right now), but he said that
> > if those were resolved, he would consider switching.
>
> <snip>
>
> As I see it, there are a couple of reasons why Sawfish has been more
> popular than Scwm:
>
> 1) Performance (esp. startup) of Scwm is still poor. I fault Guile
> mostly here, as we all know that Guile's not got the fastest startup
> time. (Things are improved in 1.4, to be sure, but not enough, yet.)
>
> 2) Sawfish is cleaner inside (Scwm is based on fvwm2 and has a lot of
> cruft -- we started with fvwm2 and converted, John started small and
> built up, doing things right from the start... we were more
> feature-complete earlier, but less agile moving forward).
>
> 3) Sawfish has better theme support (largely derives from point 2, above)
>
> 4) Sawfish benefits from John being the author of librep and being able
> to exploit the extension language subsystem more completely. Though
> I've been (or at least once was) a substantial contributor to Guile, I
> not only do I not understand Guile nearly as well as John understands
> librep (actually, he understands librep probably better than anyone
> understands guile), but I also have had to argue for the changes I
> wanted to guile, rather than just make them myself. I'm not complaining
> about that tradeoff (as I value the stability of Guile and recognize
> Scwm is obviously and thankfully not the only client of guile), but just
> observing that it's a hindrance towards making improvements to Scwm that
> extend into the extension language.
>
> 5) Sawfish has intentionally stayed lean, rather than adding every new
> cool module to the core distribution.
>
> 6) Some highly dynamic, extensible things are slightly more awkward in
> Scheme than in Lisp. (E.g., bindings that want to use symbols to bind
> to are complicated by the module system; the alternative, using the
> procedure object, means that when the procedure is re-defined, the
> binding needs to be re-made.)
>
> I'm curious what John's list of what he needs in Guile to want to switch
> Sawfish to using it is. John?
>
> Thanks,
> Greg
> Scwm Maintainer
> P.S. Expect a Scwm that works w/ Guile-1.4 to be released by month's end
> (already works in CVS, modulo some bugs w/ Fvwm2 modules)
>