This is the mail archive of the
mailing list for the Guile project.
Re: (Meta) Guile and direction
I don't think you understood my arguments at all.
Part I - about the syntax; I don't want a class-based object
system and I have already stated this a willion times in this
thread. I want a syntax that makes code smaller and easier for
classheads to learn. Afterwards someone even told me CLOS
_does_ have such a syntax, using a colon as delimiter (foo:bar)
so I don't think it's so big a deal.
Part II - focus; my problem here is that there are about 3
groups within the projects with different goals, none of which
are the same goals advertised in the Guile homepage. Everybody
knows development with no analysis/design is futile; you can't
efficiently solve problems if you don't know WHAT problem
you're solving. Guile isn't progressing; it's wandering around.
Everytime someone thinks one feature is cool this feature is
implemented and that's about it; there is no "manifesto", no
roadmap, wishlist, design spec or anything like that.
Worse, as there isn't a clear direction, everytime a cool
feature is proposed it generates endless polemic (I'm not
talking about my little syntax proposal; even universally loved
stuff like goops and the environment system generated more
flack than we would like to see in such a project) because it
isn't clear at first sight whether this new proposal helps,
hinders or doesn't affect the overall project goals.
Because THERE ARE NO OVERALL PROJECT GOALS.
What I'm asking here is simple; discuss around and find out
what are the Guile Project's goals. If possible, write a
roadmap. Then update the Guile homepage to reflect the results
of this discussion.
It's easy to think "damn this guy is nuts, of course Guile has
a direction, I wish he'd just shut up". Ok, if you think Guile
"obviously" has a direction already, please post a reply to the
list telling people what direction is that in your opinion and
watch as most of the others disagree.
From what has already been said on this list, I can propose a
few different goals to be chosen from (non-exclusive list):
- the generic extension/scripting interpreter and library that
is described in the Guile homepage
- the coolest Scheme interpreter/library ever (ok this can be
- (as someone suggested) a Scheme implementation meant to
"bring Scheme to the masses" (this _must_ be elaborated if it
is the correct choice)
Note that these aren't really mutually exclusive; the point
about stating goals is stablishing priorities.
Please everyone, at least consider the vague possibility that I
am right this time.
On Fri, Apr 07, 2000 at 10:05:08AM -0500, Jim Blandy wrote:
> Lalo, this discussion has gotten out of control.
> The approaches to object orientation that CLOS and C++ represent have
> important and fundamental differences. It doesn't make sense to pop
> in on a project, suggest that a fundamental piece of design must be
> reversed for the good of the project, and then get mad if people
> Yes, CLOS is different. But Scheme is pretty darn different to begin
> with. Honestly, if I accept your argument that we must give people
> what they expect, I don't think the changes would stop at CLOS.
> It seems to me that CLOS is much more in the spirit of Scheme / Lisp
> than a C++ - style object system. I think there are arguments on both
> sides, but I think CLOS is a comfortably defensible choice. If you
> disagree with us, it doesn't mean that either we or you are off our
Hack and Roll ( http://www.hackandroll.org )
News for, uh, whatever it is that we are.
pgp key in the personal page
Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar