Re: GOP2-3 - GLISS or not

[Ian Hulin]

Hi Graham,

On 24/07/12 10:09, Graham Percival wrote:
> 
> Hopefully we can settle those questions now. 
> http://lilypond.org/~graham/gop/gop_4.html
> 
> 
> ** Summary
> 
> Let’s decide whether to try to stabilize the syntax or not. What 
> type of project do we want LilyPond to be? What kinds of guarantees
> (or at least firm intentions) do we want to give to users with
> respect to lilypond 2 or 5 years from now being able to read their
> current ly files?
> 
> 
> ** Motivation
> 
> Some “computer languages” are fairly stable. A TeX or C++ program 
> written 10 years ago will probably still compile with no 
> modifications (notwithstanding the g++ 4.3 header and namespace 
> changes). The same is not true of LilyPond; even after using 
> convert-ly, there are still bits that require manual updating.
> 
> Given that, LilyPond is not suitable as an archival format for 
> music. It can produce a great pdf when you first write the file, 
> but the .ly files require regular maintenance if you want them to 
> compile in the latest stable version of lilypond. This is a problem
> for projects such as mutopia – a large fraction of their .ly files
> don’t compile with current lilypond. That means that they can’t
> benefit from recent bugfixes; users wanting the sheet music in a
> different size (say, printing a choral score as an A5 booklet) must
> delve into the ly code and make manual changes.
> 
> On a personal note, this is one of the biggest reasons I’ve given 
> up on using lilypond personally. From 2001 to 2004 I got a minor in
> music composition. I carefully kept all my .ly files but foolishly
> did not preserve the pdfs. And now, 10 years later, I’m left with a
> bunch of music that I cannot generate sheet music for. Manually
> updating the .ly files would take hours or days; I’ve started this
> process a few times but always lost interest after a few files,
> since there’s no guarantee that I wouldn’t need to go through the
> same process in another few years.
> 
> 
> ** Stability or not?
> 
> Stabilizing a language is a tricky process. If you do it too early,
> then you’re stuck with whatever mistakes or poor design decisions.
> If you do it too late, then there’s a large body of documents in
> the pre-stabilized version which will require updating before they
> run in the stabilized version.
> 
> I see two options:
> 
> 1. No stability: we go back to the way things worked a few years
> ago. When a programmer wants to change something, he changes the
> code and maybe adds a convert-ly rule if it’s convenient to do so,
> otherwise just adds a warning to the NEWS. I stop telling people
> “no, don’t change the syntax, and don’t even talk about changing
> the syntax”.
> 
> 2. Define a subset of input as being stable for the 3.x branch. We
> add regression tests for that subset of notation and forbid running
> convert-ly on those files. At the moment, I imagine that the subset
> would consist of at most Notation sections 1.1 Pitches, 1.2
> Rhythms, and the overall file organization; nothing else.  Changes
> to input other than that subset are fine.
> 
> My personal preference is to stabilize a subset. It won’t solve all
> the user problems with manually updating ly files, but it would be
> a step in the right direction. If the process goes well, then we
> can have additional rounds of stabilization where we expand the
> stable subset.
> 
Definitely, definitely option 2.
O.K. it'll be a PITA getting from here to there, but one of the big
wins LilyPond has it that the files generating the music are not
locked in to a proprietary format, and are text files.

If we go back to a free-for-all, it-seemed-a-cool-idea-at-the-time
idea for the language this baby will certainly get thrown out with
some future bathwater.

If we have a stable language core, then we could, if someone does have
a wild, hairy-arsed idea, catch it at proposal/review time and have
consider a solution that does fit into the spirit of our core syntax.

On the projects I worked on back in the day, we produced a software
product, which was, like LilyPond, translated into lots of languages
(I18N), and could be customized by customer sites or re-sellers.

This caused some issues when supporting and developing the product.
One of the things we had to be crystal-clear about was the
dividing-line between the base control language and customizations.

LilyPond needs to draw this dividing-line now, but be prepared to
support users like Mutopia with getting from supported by 2.16 and
therefore supportable for the future.

Cheers,

Ian