Re: [SPAM] Re: Serious feedback and improvement headroom

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 09.04.2014 11:53, schrieb Jan Warchoł:
>
>> Concerning compilation speed - this is indeed a serious problem for
>> LilyPond, and i don't know which part of the code is most responsible for
>> this.  Unfortunately i expect that changing this would require at least one
>> experienced programmer spending a lot of time (3-6 months?) just on that
>> issue.  So, unless David would like to tackle this (and unfortunately this
>> is not exactly his area of interest),

It's actually the area I am so good at that I never know where to start
and end up doing nothing.

It's mostly a straightforward benchmark-and-improve cycle.

>>>> In the current environment?  I don't think all that much.  The important
>>>> thing remains the creative process, and that does not (or should not)
>>>> involve running LilyPond.

>> 2014-04-04 16:42 GMT+02:00 David Kastrup <address@hidden>:
>>> That's about one page every 50 minutes.  12 seconds are not much for
>>> that as long as the tools don't require you to recompile for doing every
>>> trivial little correction.
>>
>> I confirm that 0.2 vs 12 seconds does make a big difference.  During Fried
>> songs beautification, i have waited probably 4-5 seconds (on average) and i
>> considered it waaay too slow for effective and pleasant work experience.
>>
>> This is because with any non-trivial music (i.e. with any music more
>> complicated than "twinkle, twinkle, little star" - really) there _is_ a lot
>> of little corrections that require recompiling to check if they were done
>> correctly.

So the thing to do is making LilyPond do them right.  LilyPond is _not_
the tool to use for a graphical workflow.  This is like listing the time
you spend straightening out nails when using a screwdriver to drive them
into a wall and asking for a faster screwdriver to make up for it.

> I can fully second that.
> This isn't like "we want a graphical workflow". We _do_ want a text
> based workflow, but visual feedback _is_ important for a number of use
> cases.

But why would you even want a text based workflow for a fundamentally
graphical task?  Of course we need LilyPond to do a better job here.
Instead people want easier ways to do LilyPond's job and basically say
"it is ok if LilyPond sucks at positioning music since we are going to
clean up after it anyway".

> And the issue was currently newly pointed at from the perspective of
> another engraving program that shares a number of aspects with
> LilyPond but _does_ manage to provide this kind of near-instant
> feedback.

If that's the priority rather than automatic typesetting, then you have
to _start_ the design with that priority and keep throwing everything
overboard interfering with it.  Which includes the majority of automatic
positioning algorithms.  And extensibility.

And then it makes _perfect_ sense to build the application around
graphical interfaces and instantaneous feedback.  If Amadeus were not as
old as it is, that's likely what it would have started out with.

> To some extent we will probably have to live with that because nobody
> will want to go back to write 80s code without all the conveniences
> modern programming systems have given the programmer (at the cost of
> runtime speed). And because nobody's available to tackle significant
> improvements in that direction.  I think this means that we should
> think more in the direction of partial compilation. I have some ideas
> but didn't have the time so far to bring them to the shape of a
> concrete question/proposal.

Let me be quite straightforward here: architecturing "partial
compilation" into a global optimization framework like that of LilyPond
is a buzzphrase that may be fun to throw around.  But it will end up
more work and less useful than cranking LilyPond's speed up by a factor
of 4.  And it will be quite useless for an actually text-based input
mode of LilyPond rather than a tool detached from the input like Denemo.

If you take a comparative look, Display PostScript was a footnote in
history, and it _never_ resulted in some tool where you would work on
creating PostScript files manually with some form of "partial
compilation".  PostScript is not structured enough for that, and
LilyPond is not structured enough for that.

It's not just a matter of architecturing systems for interactive
response, it is also a matter of architecturing input structures
amenable to incremental interpretation.

-- 
David Kastrup