Re: Do we really offer the future?

[PMA]

Kieren MacMillan wrote:
> Hi Pete,
>
> > So major compositional changes -- the ones we're
> > calling "structural" here -- are implemented at that
> > first (gen.purp.prog.lang) level, tossing LP not much
> > to trip over then or fail to carry through.
> >
> > My point, then: Why stuff a complicated-enough
> > engraving program with (compositional) issues
> > that by nature demand more abstract handling?
>
> Here are two real-world examples, drawn from my own recent life.
> ...
> In both scenarios, the prospect of editing and rewriting is quite daunting,
> given the structure of the Lilypond code and its identified limitations in this
> area.
>
> Call it a “compositional” issue if you want… but post-hoc manipulation/
> modification of large [and thus code-heavy] scores are a fact of life,
> and the easier we can make it for [power-?]users to modify existing large
> scores, the better IMO. And expecting users to implement and learn a
> complicated extra toolchain is not the right answer.
>
> Cheers,
> Kieren.
> ________________________________

Hi Kieren.

I have no quibble with what you're saying, except to note that the issues
I've called 'compositional' here aren't the sort that you were dealing 
with.
Let's restate my point -- Given a compositional issue that _is_ resolvable
early programmatically and on its own -- not left for eventual conflation
with scoring issues -- then (provided you're a Happy Programmer), do!

Maybe only I needed the advice.

Cheers++,
Pete