This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: the viability of translators, and Guile itself
<snip>
Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:
> I agree very much with both Jim and you, but...
>
> I have a fairly good overview of Guile's internals and I'm not sure
> that the naive reader of recent posts on this list with benchmarks
> where Guile shows "poor" performance, complaints on the quality of
> code, and talk about limitations in the internal architecture of Guile
> gets a proper picture.
>
> I feel like adding that many parts of Guile are good. Those parts of
<snip>
No doubt lots of Guile's implementation is good. And the parts that are
harder to grok are that way for performance. That's all fine. You're
exactly right that what matters more is any (false, hopefully)
perception that the code is so obtuse to make it too hard for the smart
people working on Guile to make good progress.
It's a PR-thing, really. There are some high-profile shortcomings of
guile that don't seem to be being addressed adequately (documentation,
startup-time, translators). One of the reasons we chose Guile for Scwm
was the promise of its getting better, and it has. But it hasn't gotten
better nearly as quickly as we (or at least I; I won't put words in
Maciej's or the other Scwm contributors' mouths) had hoped.
> I don't think the current state of the implementation scares people
> away from Guile. I *do* think that if we build up a false impression
> that Guile has poor performance or is hard to work with due to a poor
> implementation, that could scare people. (I don't mean that we should
> stop pointing out what should be fixed.) And of course, even more
> importantly, simple things like the startup time has a large effect on
> the popularity of Guile.
Exactly...
> My point is that in this example (startup time), the apparent reason
> is that Guile is slow due to poor implementation while the *real*
> reason has to do with current personal and project priorities and the
> development process and has *nothing* to do with the implementation.
But there is no reason why some of these things couldn't go on in
parallel given enough people interested in fixing them. How many people
do have write access to the Guile CVS sources?
Incidentally, I don't think just reducing the amount of code to load
initially will help Scwm's startup time... we, like other applications
that choose to use Guile, have lots of application-specific guile code
that needs to be loaded at startup. I think faster reading of the code,
or alternative means of loading standard modules (dumping, or
pre-compiling code and linking in .so files) is a more useful way to
attack this specific problem of slow startup time.
<snip>
Greg