Re: Appreciation / Financial support

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Tue, May 29, 2012 at 3:01 AM, David Kastrup <address@hidden> wrote:
>
>> Bad input tends to let LilyPond segfault.  You need C++ for that: it
>> is not possible in Scheme alone.  Take a look at listener.cc, one of
>> our simplest C++ classes with things like
>
> From a user perspective, there is little difference in getting a
> Scheme level stacktrace or a segmentation fault. (I am assuming he is
> not doing any scheme hacking). By itself, exchanging core dumps for
> scheme stack traces is not that valuable.

>From a developer perspective, it is.

> While the scheme integration have been a big leap forward in terms of
> expandability and flexibility, I think it has also been our gravest
> design error. Both for technical reasons (GUILE is a poor
> implementation), but also for practical reasons: writing scheme is
> hard for the general public, and it has surely decreased the amount of
> developer participation we've had.

Writing C++ code is not possible for the general public since it means
recompiling matters.  Do you really want to suggest that people would be
fine with writing C++ for every situation where now Scheme is being
used?

The main beef I have with Scheme as an extension language is that it is
too rich.  There is no longer an obvious way of mapping every LilyPond
feature to Scheme.  I think that is one reason that Emacs is more
successful with its Elisp than Common Lisp based clones were.  These
days I like Lua, but that train has more or less left.

But C++?  Forget it.  If that were a good idea, people would extend
Emacs in C rather than in Elisp.  And it is exactly because of Elisp
that Emacs took off.  Not because it is a great language, but because
you can mess with it, and it is well-natured.  Crashing Emacs with bad
Lisp code is much harder than crashing LilyPond, but then losing an
editor session is more of a nuisance than losing a compilation.

> For this reason, I feel scared of the plan to move large, working
> parts of LilyPond from C++ to Scheme.

The point is that adding new parts to the C++ parts is hard.  Look at
the stuff people enjoy playing with Scheme engravers, and Scheme
engravers are an afterthought fitted inside of a C++ engraver only
so-so.  We have several people suggesting Scheme solutions to problems
on the LilyPond user list.  Would they suggest C++ solutions?  Wouldn't
that be more of a problem than a solution?

Scheme might not have been the optimal choice, but it beats not having
an interpretative layer, and our interpretative layer is still much more
limited than desirable.

-- 
David Kastrup