Discussing Guile and revising interfaces

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> We keep on using and improving guile and this requires us to search for
> things that have to be improved.  That's what free software is for.

[...]

> I hope that my style of discussion does not lead to a different
> assumption about my attitude towards guile's developers either of
> today of former times.

No, not at all.  I think you discuss in a fair way, using strong,
relevant arguments.  Please continue to do that!  :-)

But I'd like to make one comment here:

Generally, I like your views a lot.  The fact that you care for what
is "beautiful" gives me very high confidence in your changes.  I think
"beauty" is a very important property of the kind of system which
Guile is.  I also believe that this criterion leads to usefulness.

Regarding scm_create_hook, we have some differences of opinion which
have to do with priorities and which perspective on the use of the
function we have, but this is a different discussion.

However, above you say that we should "search for things that have to
be improved".  I think we have found them: reference manual,
environments, module system, fast loading of code etc.  To get these
things working now is far more important than revising the interfaces.

Revising the interfaces *is* very important, and it is planned.  It's
just that this is not a good phase to do it.  I'd love to have the
kind of discussion we have had about the hooks, but *later*.  Right
now, the time I spend on this is subtracted from my work on
integrating GOOPS.

Ideally, the interfaces should take their final shape as soon as
possible, because we don't want people to get dependent on bad
interfaces.  However, we don't yet know how the final shape should
look like.

If we developed Guile in a different way, by designing and
writing specs, and then implementing it, it would be easier to know
ahead.  If you're interested in the interface issue, I'd prefer if we
started working on a document specifying Guile's future interfaces.
Such a document could be used to guide development, and before that it
is easy to make changes without bad consequences.

I also think deficiencies in the areas I refer to above
are worse than the interface issue.  Loosing a creative application
writer because Guile loads slowly, or because of lack of
documentation, is worse than forcing him to make changes to his
application when a new Guile is released.  (This doesn't mean it isn't
important to keep the interfaces stable.)

So, I'd like to urge for postponing making changes to older parts of
the Guile API until later.