RE: (problem? 'guile)

["Shriram Krishnamurthi" <sk@cs.brown.edu>]

Hi Manuel,

Sorry for the delay replying -- your message came while I was on the
road.

> Recently reading c.l.scheme, I can see that Shriram Krishnamurthi
> seems to doesn't really appreciate the Guile approach to
> Scheme. This
> is not a Troll, but while I'm about to consider using
> MzScheme rather
> than Guile (as I've done from now), I'd like to see
> arguments of what
> makes MzScheme "better" than Guile ?

This is a complex question without a simple answer.  The problems with
Guile are rooted both in process and in technology, and these are
interrelated.

The problems with process are, simply, that I don't think the Open
Source model is a good way to design a *language*.  It's great for
producing libraries, especially ones that solve standard problems
(such as providing access to common protocols).  But language design
usually needs a focal point of control, and this person should ideally
be as literate as possible.  My sense of Guile is that the person in
charge has changed regularly -- either that, or different people think
they're all in charge, which is a different kind of problem.  As such,
it offers no central design philosophy that I can pin down.

I also don't trust that some of the people (who have said they are) in
charge know a heck of a lot about what they're talking about.  I've
had several questions about Guile's libraries, and also some of its
linguistic features, some of which are documented on c.l.s and on SRFI
mailing lists.  I've seen Guile code that was so full of side-effects
(gratuitous ones, I might add) that you might as well be programming
in a first-order imperative language -- so why bother with Guile?
I'll provide you one illustrative example, which reflects the last
time I had any contact with Guile.

I was looking over one of its networking libraries, and noticed that
it reflected an underlying C library's interface directly in Scheme.
So far, okay; indeed, we've suggested on this list, in the past few
days, that this is exactly the right thing to do.

It went further, however, to mirror the C library *exactly*.  In
particular, where the C library consumed pointers, Guile passed it the
pointers it wanted.  In the process, it introduced variable aliasing.
This, also, should not be particularly surprising -- C is notorious
for the presence of variable alasing.  Scheme, on the other hand, *has
none*.  The presence of aliasing introduces umpteen problems for any
kinds of tools -- anything from value flow inference to type inference
to compiler optimization to ...

We went over this several times.  It was clear that I was making no
progress at all explaining the implications of this problem with my
correspondent, one of the self-style designers of Guile.  About the
fifth iteration, I finally broke with the conventions of politeness
and asked him, bluntly, whether he had any idea about what aliasing
was, and thus what I was talking about.  His answer: he didn't have a
clue.  I then asked him why he was designing a programming language.
His response was, quite simply, because he could -- that was one of
the joys of the Guile model.

Quite simply, I don't want a language with that kind of designer.

Shriram