Re: lilypond progress

[David Kastrup]

Arne Babenhauserheide <address@hidden> writes:

> David Kastrup writes:
>
>> Arne Babenhauserheide <address@hidden> writes:
>>> This choice is much, much better than before. The choice before was "I’m
>>> losing Lilypond!" (and not much of a choice).
>>
>> No, the choice was "I need to use the installer provided on LilyPond's
>> web page".
>
> Then let me rephrase: The choice for most GNU/Linux users was "I’m
> losing Lilypond", now it is "Lilypond might be slower".
>
>> Frankly the only feasible choice for users on Windows and
>> MacOSX for the last ten years, and we have a _strong_ followership
>> particularly among Windows users.
>
> That’s good, but for them there never was a problem, right? It does not
> matter for them whether Lilypond devs compile for Guile 1.8 or for Guile
> 2.x
>
>>> and no longer a roadblock users cannot cross without losing all
>>> ability to compile their music. And it is something which hits people
>>> who might actually have the skills to fix it (those who embedded
>>> scheme in the lily documents).
>>
>> That's far too optimistic since many expressions provided to LilyPond
>> functions are delivered in "embedded Scheme" (every occurence of # in a
>> LilyPond file causes the Scheme reader and interpreter to run)
>
> This means that the user knows that the embedded Scheme is there,
> right?

No.  For many, #0.5 is just how you have to write floating point number
arguments to LilyPond constructs, for whatever strange reason the
language developers came up with.

> So even if they cannot fix it themselves, they can provide the snippet
> which creates the problem. They know where to start.

Since when was "show somebody else the source" something new with any
batch processing system?

>> and besides, much of the core functionality is defined using
>> "embedded Scheme" as well, making it just as crash-prone as
>> user-defined code.
>
> This can be fixed incrementally, too.

I don't see how incremental fixes could apply here since the problem
does not lie with the embedded Scheme.

> I might sound too optimistic. I think that’s needed to provide a new
> perspective which can help to reduce the negative bias from the
> problems in the past years.

I think you are comingling personal and technical problems here.  The
latter are not amenable to positive thinking.  The former certainly have
lots of potential for improvement.

> Please allow me to provide this as a spark of happiness and give it a
> chance to support more positive feelings during collaboration.
>
> It might still be a few years until Lilypond on Guile 2.x is as stable
> as Lilypond on 1.8, but the main roadblocks have been removed:
> Lilypond can already compile complex ly files with Guile 2.x

The "main roadblocks" in relation to which goal?  To make Guile 2 a step
forward as compared to Guile 1, we are more or less struggling to reach
the starting line, namely being able to use Guile 2 reliably enough as
to be able to start targeted, well-defined, effective and reasonably
achievable improvements.

-- 
David Kastrup