Re: goops/guile doc (was Re: Simple example program to illustrate Goops)

[Jim Blandy <jimb at red-bean dot com>]

[Replying to old mail...]

I think it's a mistake to try to make GOOPS look like C++, or Visual
Basic, or Java.  The CLOS approach is just really different, and
anything that tries to hide that, I think, will be weird and
confusing.

I think the only winning approach is to simply document what GOOPS
really is, and do that well.

I think imitating the examples that appear in the Perl and Python
documentation is a good start, but we should also try to show the
cool features unique to GOOPS.

For example, the picture Smalltalk, Java, and that gang paint of class
hierarchies and method calls is a creature you'll never see anywhere
else; the hierarchy appears as a result of a particular idea of how to
implement things, not because it's the only natural way to think about
the problem.

In contrast, the way CLOS (and thus GOOPS) thinks about things is much
more like mathematics, where you define various types of objects ---
this is a set; this is a graph; this is a group; this is a field ---
and then you define operations on them: `intersection' is an operation
on two or more sets; `reachable' is a function on graph nodes; and so
on.

In mathematics, you wouldn't hesitate to say something like:

    image (F, S), where F is a function and S is a set,
    is the set T of things you get by applying F to something in S.

Here you're specifying the types of both operands.  This is like
specializing a generic function on two of its arguments, which Smalltalk
and Java can't do.

This has more practical consequences, too.  For example, folks were
just talking about binary I/O functions, and it was pointed out that
it makes sense to apply them not only to streams, but also to strings,
byte arrays, hypothetical pointer types, and so on.

Well, suppose we defined generic functions `fetch' and `store'.  Then
suppose we define a GOOPS class <representation>, which has elements
like 16-bit-be-unsigned-int ("be" == "big-endian"), 32-bit-le-signed-int,
64-bit-ieee-float, and so on.

Then we could define methods like

   (fetch <representation> <string>)

to be one set of fast primitives, written in C, and

   (fetch <representation> <port>)

to be another set of fast primitives, written in C.  Then we just let
the GOOPS dispatch choose the right function for the particular
representation and data source.

The point here is that it's actually really natural to think about
specialization on all your argument types.  It's really the way you
always used to think about things, before everyone told you that
methods belong to classes, so you have to pick one object to be
special, and a method call is always invoking a single object's
method.

In the example above, it doesn't really make sense to say that the
particular `fetch' function we end up calling is a method of the
<representation> class, or the <string> class --- it's both.  It's
just the code for extracting 16-bit big-endian ints from strings ---
it's the method of both classes.


It's a mistake to try to sell something that's genuinely different, in
a good way, as being "just like this other stuff you already know."
Don't sell to the lowest common denominator; do the most awesome job
you can, hook the people who are quick enough to appreciate it, and
let the rest of the world catch up in their own time.  If your idea is
really as good as you think it is, it'll catch on eventually; you
don't need to misrepresent it.

Corollary: if your idea dies out, maybe it's not such an awesome idea
after all.

But maybe it'll inspire someone else to try to revive it later.
That's why Lisp is still around: it's never been mainstream, but
people think it's so cool that they're always reviving it.