John Chambers wrote -
>Standards are good mostly if
>they can specify a practical minimum that turns out to be useful for
>a large set of people. The ANSI C and POSIX standards are two good
>examples. They can also be dead ends that block innovation.
As you have rightly said, nobody can force anybody to follow the standard.
abc doesn't have an army of in-house lawyers waiting to pounce on miscreants
who deviate from the path of righteousness (sorry, mixing my metaphors).
There is no way that anyone can block innovation. What I'm asking for is a
cooperative attitude so that developers can look at the existing standard to
see if what they are doing has already been done or conflicts with anything
else that has been done.
>It's easy
>to end up with a spec that can't be implemented correctly, and/or
>turns out to be not quite what people need. There's a set of good
>(i.e., bad) examples in the POSIX spec, in the form of functions such
>as gets() which turn out in retrospect to have been major errors.
I don't know anything about the history of UNIX but it sounds as if the major
errors occurred before the POSIX spec was written precisely because there was
no coherent development strategy. The spec simply drew attention to mistakes
that had already been made.
>One thing that helps a lot is the general rule "Anything not in the
>standard is optional. Programs can ignore such things, but they
>should not reject them." This was pretty much what Chris said with
>abc, and it's a good guideline. If we haven't decided on something,
>we just say that it's not specified. This encourages developers to
>try ideas, present them to users, and see what turns out to be most
>useful.
and we end up with several different and incompatible versions of the
V: command and the ambiguity that Henrik Norbeck has pointed out when mixing
P: commands and repeats and goodness knows what else. Once something is
introduced it will get used and you'll never be able to get rid of it no
matter how crap an idea it is.
>I'd sorta hoped that some of my earlier proposals would end up in
>some sort of standard. They do seem to have just quietly disappeared,
"sorta hoped"? "some sort of standard"? Who did you expect to do this? You
are on the standards committee John. (Set up over a year ago by invitation
only with the express purpose of deciding the standard by private discussion
amongst the six members away from the abcusers list. Cabal? Of course not.)
[Aside
>The right solution would be to
>start a campaign of assassination of those programmers.
Won't work. Cut off one and three will grow in it's place.
[End aside.
>Well, of course, you can. [include anything I like]
>And if it's useful to a lot of people, we
>can get a campaign going to standardize it. If not, we'll campaign to
>make you an outcast. ;-)
When I first joined this list I naively assumed that the idea was to discuss
ideas and, if agreement was reached they'd be introduced into the standard.
Then all developers would implement them. I tried to argue in favour of an
explicit key signature and became a social pariah. I think the main
responses were "The tonic should be compulsory in the K: command.", "We like
it the way it is.", "Don't do anything that is incompatible with abc2win.".
You, on the other hand, went ahead and did it and nobody took a blind bit of
notice. I will implement it in my new programme. (Partially)
>| (And, of course, if I put my MCP logo on the website, I can lay claim to
the
>| whole of abc on behalf of Microsoft-axis-of-evil.)
>
>Careful there. If you do that, you had better stop talking to the
>rest of us.
Only kidding. (Anyway, I thought a lot of you would rather I did stop
talking to you.) Isn't this even more reason why there should be an abc
standard?
>There are a lot of people using non-Microsoft systems
>here. Some of us even use (gasp!) Open Source software.
There are also a lot of people who are using Microsoft systems. The problem
with Open Source is that it operates at the code level. One of the strengths
of abc is that, being text based, it works across all systems so sharing
would be better done at the
specification/documentation/standardisation/whatever level.
>communication between Microsoft developers and
>other programmers will soon be illegal in the USA.
I don't live in the USA. Over here a contract isn't binding if it breaks the
law. Get your human rights and restrictive practices legislation sorted out.
Bryan Creer
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
