Re: should GOOPS be built-in?

[Greg Harvey <Greg dot Harvey at thezone dot net>]

<knotwell@knotwell.f5.com> writes:

> 
> Personally, I think a large reason is a lack of focus.  At the risk of
> repeating discussions from months ago, guile tries (IMO) to be
> everything to everyone.  From several recent discussions, guile is
> used as an embeddable scheme interpreter, a standalone scheme
> interpreter, or a generic library (I found this especially
> fascinating).  It seems to me that this makes the already difficult
> job of balancing priorities even *more* difficult than it could be.   
> 
> FWIW, I'm in the standalone interpreter camp. 

Yeah, but then we'd have to change the name to GUIL. The big, official
purpose is embeddible general purpose language interpreter; making the
scheme side better obviously improves the final result, so the goals
aren't necessarily exclusive.

> 
> In any case, if I needed to embed an interpreter, I wouldn't choose
> guile.  I would choose either mzscheme or python.  There are two
> reasons for this:
> 
> 	1)  lack of preemptive threading (relatively major downside)
> 	2)  lack of documentation        (HUGE downside)

Docs yes (I'm pretty sure we've beaten this one to death). I'd expect,
tho, that most people aren't too concerned about preemptive threading
(probably because most of us are running on single cpu systems, so
we'd end up with worse performance on account of it ;).  It would
definately be a good thing, but it's also a lot of work (guile is
barely coop safe in places) and it isn't as critical as some of
guile's other shortcomings. That being said, I fully encourage anybody
interested in this to go to it :)

>  > 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?)
> 
> Personally, I think this is where the Linux dual-release model (stable
> v. development; BSD has something similar) shines.  In my case, I
> could "afford" to use hypothetical development releases of guile.
> This is because I don't use it for anything critical.  

I don't disagree with this (alright, I said it before too :). 

> Why a "development release" (as opposed to just building what's
> currently in cvs)?  First, it works for those of us who've firewall
> administrators unwilling to open the cvspserver port.  Furthermore, a
> development release gives the "interested us" a feature list to
> investigate.  Finally, it's more efficient.  It's (IMO) unreasonable
> to expect *every* downloader to debug any patch issues.  To use a more
> concrete example, I seem to remember a version of the generational gc
> that needed to be built against a particular date's cvs tree (BTW:
> this is not meant as a criticism. . .I would've probably done the same
> thing).

Actually, it didn't necessarily need that (and should've applied to
previous versions, with fuzz); but it is more a problem of the
cvs/diff method often not being too brainy about conflicts (this is
the reason why those `open' licenses where you can only distribute
changes by patches suck). There's nothing I hate worse than getting a
patch where you have all these odd things happen when you do a patch <
stuff.diff; I stressed the particular cvs version to make sure that
people interested wouldn't have to deal with all that crap. The
patches for the next while will be against 1.3.4, so that's easier ;).

>  > 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.
> 
> Personally, I think extractable docstrings are a good way to go on this
> front.  Much deserved applause to Greg Harvey!

You want to be thanking Greg Badros here :).

>  > 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. 
> 
> To finally put my response on topic, I personally think goops *should*
> go into the core if people want guile to have a CLOS-like object
> system.  In my mind, it's unreasonable to say "goops is the blessed object
> system, but we shouldn't put it into the core", because goops will never get
> any wide use.  NOTE:  if goops is left out of core, it seems
> reasonable that it's inclusion should as simple as a compile flag (via
> configure). 

I'm not saying goops shouldn't go into the core (I also think goops
*should* be in the core), but I'm saying that it should have
documentation before it's added: if not, then it still won't be used
very much. However, it looks like someone's started to work on this,
so hopefully this point will be moot before too long :)

-- 
Greg