Re: GOP2-3 - GLISS or not

[Bernard Hurley]

On Tue, Jul 24, 2012 at 11:48:13AM +0200, Francisco Vila wrote:
> Take this as the result of a quick reading of the summary. My comment
> as a non-expert is that probably a good, reliably working convert-ly
> is a substitute for syntax stability,

I disagree. For one thing it is often very difficult to map new syntax 
precisely onto an old.
There are bound to be people who use lily in a way that the designer of a 
syntactic construction did not expect because 
they find it "works for them." So even if all the expected uses convert 
properly that is no guarantee that convert-ly 
will work from the users point of view. Many people are put off using a program 
by even one perceived hassle.

I have a lot of ancient lily files that contain things like bits of scheme I 
wrote just to get a particular effect in a 
particular instance. I ended up recoding some of them from scratch because it 
would have taken too much time doing 
anything else.

Languages that have a stable core tend to last a long time. It is still 
possible to compile and run the vast majority of 
COBOL programs that were written in the 60's. Most of the problems that do 
occur are down to the i/o of modern computers 
being different. But this is the sort of problem a user would expect. It is 
unexpected problems that appear to happen 
for no apparent reason the annoy users.

The idea of a stable core that is never changed, except for very very good 
reasons is excellent. It could be added to as 
various other parts of the program developped. If the core were large enough 
for 'good enough' scores to be written for 
most of the repertoire, but forgetting about arcane ancient or contemporay 
notations, then a site like Mutopia could 
merely require that this subset of the language be used.

Users who want scores of reasonable quality that they want to be able to re-use 
in the long term could use the stable 
core, whereas users who want to use all the latest bells and whistles would be 
able to use the unstable parts of the 
program in full knowledge that this could lead to problems later.

Bernard