Re: Guile foreign object interface

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Andy Wingo <address@hidden>
>> Cc: address@hidden (Ludovic Courtès),  address@hidden
>> Date: Thu, 09 Mar 2017 20:56:09 +0100
>> 
>> > That's what I'm trying to tell you: there's no aggression.
>> 
>> I understand that different people can have different reactions and it's
>> great that you can look through "style" to the substance.  I and a
>> number of other contributors (evidently including Ludovic) find it hard
>> to do so, and the only reason we try is because we care about Guile.
>> It's really weird though to try to ignore this "style" when the style
>> often says precisely that we _don't_ care, in those words, and other
>> times in as many words.
>
> Given the certain amount of frustration over the real problems that
> didn't get solved until now, you can understand that, don't you?
>
> I had my share of problems reported here, mostly with working patches,
> some of which took many moons, sometimes years to get solved upstream.
> So I think I understand some of David's frustration, although the
> problems I reported were nowhere near the gravity of those Lilypond
> has.
>
> So maybe the project leadership should try to improve the efficiency
> of handling bug reports and of catering to the problems raised by
> projects using Guile, as a means to lower frustration and make the
> environment friendlier?

The "project leadership" in Free Software more often than not does not
have any assignable resources so there is little point in venting
frustration in that regard.  My concerns are not as much about lack of
progress but rather about moving Guile in a direction where it becomes
increasingly unfeasible as an extension language not just for LilyPond
because extensive interaction with other programming models and
languages becomes too expensive, invasive, fragile and inflexible.

To a certain degree one can chalk this off as "growing pains" that
long-standing users have to shoulder, at least when working with
development rather than stable versions.  But without a visible intent
of actually prioritizing or even addressing those, you end up with more
like a "one step forward, two steps back" approach rather than the other
way round, at least for already established uses rather than those for
which the steps forward are explicitly intended.

LilyPond is getting removed from distributions these days because it
requires Guile-1.8.  Probably even worse, some distributions deliver
binaries linked with Guile-2.0 (the options available for compiling with
Guile-2.0 support are only intended for developers) which means that the
binaries are not usable for serious work (far too slow and unstable).

This situation has been developing for a number of years.  It would
probably take less effort to address to a tolerable degree than making
Emacs-on-Guile more than an academic option.  And make no mistake: there
is quite an overlap in problems that need solving for making
Emacs-Guile2 viable and making LilyPond-Guile2 viable.

But Emacs does not suffer the same amount of migration pressure since
there is no independent Elisp project in different iterations involved.
It can just stick with what works, short of a political decision (like
the one that put MULE into Emacs 20, costly then, amortized by now).

-- 
David Kastrup