Re: should GOOPS be built-in?

[Maciej Jennifer Stachowiak <mstachow at alum dot mit dot edu>]

Greg Harvey wrote:
> 
> Actually, I think there are a variety of reasons for
> this. Documentation is one, but you're right that it's not necessarily
> the biggest one.
> 
> Guile is like most other projects out there, in that the people
> involved can be separated into two categories: people who do stuff,
> and people who say stuff. Now, ordinarily this forms something of a
> symbiotic relationship: the people who do stuff can pay attention to
> the people who say stuff when the stuff they say is smart, making the
> stuff that's done better; or they can make fun of the people who say
> stuff when the stuff they say is stupid, which provides an outlet if
> you're stressed out after doing stuff; stuff is still getting done,
> and people who like to say stuff have a lot of stuff to say stuff
> about.
> 
> In guile's case, though, there are some fairly serious problems (and
> not because there are more people who just like to say stuff... there
> are *always* more people who just like to say stuff):
> 
> One is that doing stuff has often been an exercise in futility. People
> do stuff. The stuff is totally ignored. People no longer feel like
> doing stuff, and go off to hack at the linux kernel, where at least
> there's the chance of getting in on the next big IPO.
> 
> Second is that the people who say stuff aren't particularly willing to
> try the stuff of the people doing stuff, so the stuff that's done
> isn't always high quality. People doing stuff become tired of feeling
> like the boy in the bubble; at least he had a deck of cards (note:
> can anybody tell me where that came from?)
> 
> Third is related to documentation: it's hard to do stuff when you
> don't know how other stuff works. There are possibly more people who'd
> do stuff if they didn't have to dedicate so much time to discovering
> other stuff; unfortunately, to do this currently, you often have to
> get the people doing stuff to say a lot of stuff, which means that
> stuff isn't done.
> 
> The overall result is that very little stuff is done, and,
> increasingly, less and less stuff is being said, because it's only fun
> to say stuff when there's stuff to say stuff about.

Greg,

You raise many excellent points. I agree that Guile has been having
problems
staying on track and that many people are frustrated. I think the most
important
point you have raised is that the people willing to do stuff have often
had to
wait excessively long times to see their work incorporated, and as a
result
just gave up in frustration. As maintainer, I plan to put higher
priority on
getting other people's code integrated (and giving constructive feedback
if
it has problems) than on my own personal Guile coding projects.

Lack of documentation is also a major problem. But I am unsure where to
put
the focus here. Obviously reference documentation for all
Scheme-accessible
procedures and syntax is essential, and thanks to Greg's work it's
becoming
a reality. But past that, what's most important to build the kind of
community
that Guile needs to be a successful project? Should additional docs be
targetted
at people using Guile from the Scheme level, either standalone or
embedded in
an app, at people who want to embed Guile in applications, or at people
who
are interested in hacking Guile itself? Should it be in tutorial or
user's
guide form, or perhaps some more sparse form still for internals docs?

I would appreciate feedback on this issue.

 - Maciej