Re: How to make GNU Guile more successful

[Linas Vepstas]

Hey,

On Mon, Feb 13, 2017 at 11:59 PM, Marko Rauhamaa <address@hidden> wrote:
>
> Arne Babenhauserheide <address@hidden>:
>
> > Marko Rauhamaa <address@hidden> writes:
> >> Then, there's GOOPS, which in my opinion is simply an unnatural way
> >> to go about object-oriented programming. It does violence both to
> >> ordinary OO way of thinking and classic Lisp idioms.
> >
> > GOOPS works pretty well for me where I use it (for dispatch by type).
> > Could you clarify your criticism: Do you think it is bad or is it just
> > different?
>
> GOOPS starts by defining slots. Slots are an objects internal business
> and should not be visible to the outside. Instead, objects should be
> black boxes that interact with methods. For example, the port interface
> is a nice, classic OO API. You don't know anything about the slots of a
> port.


Yes, but ... maybe goops should be renamed guijs ? Javascript has this
... wonderful ... ability to just attach new data and new methods to any
"object" at runtime.   Now, I've never used goops in any serious way, so
maybe I'm quite off the mark, but it seems to me that maybe this is what
slots are trying to accomplish.

That is, when you say "classic OO API", it seems you really have C++ in
the back of your mind.  But the early days of OO had all sorts of weird ways
of saying things and thinking about things (e.g. "sending messages to objects")
that was a bigger, more inclusive tent.  Perhaps GOOPS is just OO in this
older, and now deprecated sense.

My naive impression is that some javascrtipt-ish extension to guile would
be very cool.  Perhaps goops could be pushed further in that direction.


> >> Continuations and multiple values are obstacles instead of enablers.
> >
> > I think multiple values are nice. But they are not well-integrated (I
> > have to import something to use them). Why do you think them enablers?
>
> Yes, the multiple values API is a problem in and of itself, but more
> generally, what does:
>
>     (values a b c)
>
> give you on top of, say:
>
>     (list a b c)

+1 every time I think I need multiple values, I try it, and then back
away from it.
Its a cool-sounding idea that is a consistent obstacle.


> > Why do you think that continuations are an obstacle (do you mean
> > general continuations or do you mean prompts)?
>
> Continuations prevent you from implementing Python's try/finally and
> emacs' (unwind-protect).
>
> On the other hand, I don't think any application developer would come to
> a point of thinking, "Hey, I know, I'll use a continuation!"

Continuations are stunningly-badly explained, almost everywhere.  More
or less every example I've ever seen is pointlessly obtuse and opaque,
seemingly written to demonstrate how smart the author is, and how stupid
the reader is.

There is one place where an application programmer could say "Hey, I know,
I'll use a continuation!" -- whenever they need a single "global"  "OO object"
with a "global variable" in it. I use them for implementing statistics
printing and
profiling. The idea is simple, the solution is elegant:

-- I want to have a single "global" counter which I will increment by one from
now until forever.
-- I want to have a function to increment it, and I want to call that function
at any time, from anywhere at all.
-- every hundreth time that it is called, it will print something like
"xyz operations per second"

Turns out that continuations offer a marvelously simple, easy-to-understand
easy-to-use solution to this problem.   You'd think that there would be some
tutorial or some common "here's the cookbook way of implementing this"
but I sure haven't seen one.  But once you get the hang of the above example,
one can see how it could be fleshed out into a full-fledged OO-like
message-passing system, complete with frames and slots.

Continuations do not need to be a swear word; its just that they're badly
explained.  They are a stumbling block, but that's in part because there's
no analogous concept in proceedural languages; so most programmers
never have to learn it.

> > Decorators are really cool to use:
>
> Have yet to find a need for one.

Sounds like gain-saying.  Just because you don't need it, doesn't mean its
not useful.  "A typical user uses 20% of an application. The problem is,
different users use a different 20%".  "recall there were dozens of wikis before
wikipedia, dozens of search engines before google, dozens of social media
sites before facebook"

I conclude that the difference between a successful(popular) and a failed
(unpopular) tech is often very subtle.  For all I know, decorators "done right"
in guile could skyrocket it to the top of the popularity ranking.  Or not. Just
be careful in dismissing some of these ideas.

> >> Unicode illusion. (Guile has fallen into that last trap as well,
> >> unfortunately.)
> >
> > I’m using Python and Guile for physics and math (to some degree), and
> > having good Unicode-support is great for that. What’s your practical
> > criticism here?

Unicode support in guile remains rocky and buggy, as I once again
rediscovered recently when pumping Chinese through it.

> It would be better to leave Unicode out of Guile's system interface and
> have the application encode and decode explicitly where needed.

Huh?  That would suck.  Unless I misunderstand, in which case it would
be great.   Unicode is just a bunch of bytes that are null-terminated.  Guile
does very stupidly try to  convert unicode strings into arrays of wide chars
which is absolutely idiotic, and a total bottleneck for what I do.
Its a useless,
pointless processing step.  I keep planning on submitting a patch to fix this
but never have time.

I regularly have strings that are 10 Mbytes or more, that contain mixtures of
scheme code and chinese characters (in utf8), that I have to send to guile
for eval. Anything that would make that faster would be awesome.

--linas