At 06:48 AM 16-10-00 -0700, [EMAIL PROTECTED] wrote:
>--------
>
> Bryan writes:
>
>| I will, but as I have said, abc is useless as an exchange medium if we ar=
>| e=20
>| not all talking the same language.
>
>Well, now, it seems to me that this is disproved by even a casual
>glance at the current situation. There is a fairly significant range
>of discrepancy in how various abc tools implement various parts of
>the notation. If the above were true, then abc as it is now would be
>useless. But a lot of people are finding it very useful.
Without wishing or trying to speak for Bryan, I think this misses the point
of what Bryan was saying (or at least my interpretation of what Bryan was
saying). He wasn't saying that "abc is useless", instead he was saying that
"abc is useless as an exchange medium". Personally I wouldn't use the word
"useless", but I would claim that the more variants of abc programs accept,
the less useful abc is as an exchange mechanism. That doesn't stop abc
being useful for a person who always uses the same program, or even a group
of people who all agree to use the same program, but if we want a variety
of programs to accept abc input there needs to be some idea of a standard,
and developers need to make their programs stick to the standard to at
least some minimal extent.
Unless my memory has failed me completely, there have been plenty of
postings on this list about people having to edit some abc they've
downloaded because it was created to work with program X, and is now being
fed into program Y.
>The claim that abc must be a consistenly-implemented standard is a
>red herring. This isn't true at all, just as it isn't true for any of
>the other standards in the computing industry. Standards are never
>implemented consistently by different developers. And some
>widely-used tools (such as unix ;-) have radically different
>implementations on different platforms, while still being very
>useful.
>
>This isn't just ranting. Claiming that we *MUST* all step to the same
>drummer is actually a way of suppressing innovation. If ABC is kept
>in a little box and developers are discouraged from experimenting
>with extensions, then it will be forever frozen at its current state.
>It will remain useful for a few kinds of music, but will never
>develop into a more generally useful notation.
This is taking an extreme view of the situation (and a view that I don't
think anyone has yet proposed). I could put forward the opposite extreme -
that developers just go off and do whatever they want, every developer
experiments with whatever extensions they like and we end up with a whole
batch of incompatible input languages. Neither extreme is a particularly
healthy situation - somewhere in the middle there needs to be a balance.
Part of the balance involves having a standard that is extended in useful
ways and can be quickly updated if necessary. Unfortunately that takes a
lot of work and consensus building (assuming we're not going for the
dictator model).
>Keeping abc in a straightjacket by insisting that we must all be
>talking the same language will in the long run be fatal, and will
>relegate abc to the fringe. That may be the intention of some. But
>there are a lot of kinds of music in this world, and musicians don't
>talk the same language at all. I'd rather see abc continue to develop
>as a user-accessible, emailable music notation that more musicians
>can use. This requires that we accept variations and extensions, and
>that we discuss them with the idea of developing ABC into a more
>widely-usable notation.
Again, this is taking an extreme view - I don't think anyone is out to
"relegate abc to the fringe" and I don't think the implicit accusation
helps the debate in any way.
I have a question which I think is relevant to this debate:
If a new developer were to start writing a program to accept abc input now,
which version of abc should they accept as input? Should they stick to the
currently published standard? maybe the draft standard? Should they attempt
to handle all of the abc variants out there? (this would involve getting
the instructions for a number of different programs and finding out what
they accept). If they tried to accept many abc variations should they then
attempt to keep their program up to date with changes to the other programs
- I can see a situation where an extension implemented in program X causes
a wave of changes in other programs to implement the extension. What should
they do if two programs have incompatable extensions?
To finish off with, I am going to restate my basic premise:
The more variants of abc programs accept, the less useful abc is as an
exchange mechanism.
Bob
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
