Re: what to do

[Miroslav Silovic]

Tom Lord <address@hidden> writes:

> Sorry.

Apology accepted. (this from one who rooted a long time for a usable
release of Guile, one that'd allow me to drop SCM).

:)

> I had hoped for a volunteer community that would pretty much sync up
> with my design aesthetics for Guile and that we'd have a quick and
> efficient barn raising.  I had assumed there was enough shared state
> for that to happen.

But bazaar model doesn't work that way. The point is that each team
member will have a slightly different vision of what has to be
accomplished. The final result is something of a middle ground. But
the rest of your post indicates you learned this the hard way.

> Instead, roughly five years later, I return to the field, see lots
> of lumber lying around, some not-obviously-related half-finished
> structures, and a team of volunteers who are happy to pass at least
> some the time discussing whether we want to build a round barn or a
> grand stable.  Worse still, there are some farmers around trying to
> use the half-completed structures to store things.

It is hardly that. Guile is currently a (relatively) small language
with a nice object system (I mean, *REALLY* nice object system), R5RS
compliance, the easiest C embedding I've ever seen, and a library of
the common datastructures that can be used from the C code (making the
C coding for Guile almost as easy as using the Scheme).

I'd say that most of the goals of the early Guile are satisfied or
getting there... where 'early' refers to Jim Blandy era. :)

> I think that these problems may very well be inevitable with the
> bazaar model of development.  When everyone just starts piling on
> features and contributing uncoordinated design suggestions, there is
> a tendency just to wander aimlessly around the design space until
> externally imposed backward compatability requirements freeze
> progress.  You could argue that that's good: that the random walk
> proceeds until it hits a feature set that people like.  But you
> could also argue that that's bad: a direct walk to a moderately
> distant high ground is pretty much ruled out, in the absence of
> full-time team of core developers with a shared vision.

Oh, but it's simulated annealing!

And it's probably the best known optimisation method, in absence of
the a-priory knowledge about what goals /should/ be satisfied, or
/how/. Remember, Guile is not developed after a market research,
meaning that the project goals are whatever ends up being done. IMHO,
that is as it should be (but I'm not sure I can adequately explain
this opinion).

> I experimentally dropped in to this list with a bunch of contextless
> suggestions for features from Systas that I think help make it a
> nicer dialect of Scheme.  I also raised the issues of inadequate
> testing in both implementations, and a deep design flaw in the GC
> they have in common.  But the result seems to be more the usual
> random walk around the design space.

I posted several times, basically saying that the 'deep design flaw'
is not a flaw at all. Or it's merely a documentation flaw. Either way,
for a system that's supposed to be easy to integrate with C,
conservative GC is a must (although precise GC with a peprocessing
pass deserves another look).

Testing, on the other hand...

-- 
How to eff the ineffable?