This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: should GOOPS be built-in?


Greg Harvey writes:
 > > My impression is that the Guile community in general is rather weak
 > > when it comes to actually writing code.  Now, you may argue that this
 > > is because of the lack of documentation, but that may not be the whole
 > > truth.
 > 
 > 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.

<delurk>

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. 

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)

 > 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.  

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).

 > 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!

 > 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). 

Put concretely, I wrote a publically available ftp library using
guile.  I could've used (could've used == it would've made life easier
for me *and* others) goops when I wrote it.  I didn't use goops
because I wanted others to be able to easily use the library.  If I
had used goops, they would've needed to install goops as well. I found this 
requirement unreasonable.  

 > Greg

</delurk>

--Brad

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]