Bryan Creer writes: | John Chambers wrote - | >There's no way any of you can stop me from using my own code. | | Wouldn't dream of it old chap. We seem to have completely different ideas of | what a standard means. You seem to think it's to stop people doing things. | I think it's to enable people to do things. More specifically, to enable | different people to do the same things in the same way.
Well, in practice it tends to do both. 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. This is one of the reasons that the committee approach (design the spec first, then implement it) turns out to not work so often. 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. But you have to implement them if you want certification, and then try to teach programmers to not use them. Standards are classical examples of a "double-edged sword". 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. | I would like to use your abc files but excuse me if I'd rather not use your | code. I'm sure it's excellent but it would not be very practical for me to | include it in my Visual Basic programmes. Yeah; you might have a few problems getting it to compile. | What I do want to do is use your | specification of the repeat endings since it would seem sensible to implement | the idea in a compatible way. It would be nice to know that other developers | were doing the same thing. As it happens, I can because you are very | generous in sharing your ideas on the list and I thank you for it. I was on | the list when you last discussed it so I know about it but it is evident from | recent postings that some people do not. Would it be so terrible for the | information to be held in some central location under a general abc umbrella | independant of any particular software development? 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, as have others' suggestions, though I suppose they're off in some archives. I probably also have some copies lying about, in the form of docs for what I've implemented. Maybe I should repost them. Of course, I have a few new ideas since then ... | If you don't want to | call it a standard then think of another name. No developer would have to | obey it if they didn't want to; that would be between them and their users. A term like "proposed standard" might work. I tend to use "extension", since nothing I've done is standardized. | >Meanwhile, programmers build things that work, users start using them, | | Yep, just like Jim Vint did with abc2win which, for some reason, seems to | irritate you enormously. Actually, I've commented several times that I thought that using end of line as end of staff wasn't a very good idea, and an explicit end-of-staff token would be a better idea. But that's not what was done, unfortunately. If it were a really big deal, I'd be arguing for changing everything to match abc2win. But it's really just a small deal, and it would be much better if we all implemented the (slightly inferior) standard. The only real problem with the standard way of indicating end-of-staff is the grief caused by the idiots who put line wrapping into email. This is an ongoing nightmare, not just for abc, but for programmers in any of the many languages that treat the end of a line as the end of a command. The right solution would be to start a campaign of assassination of those programmers. Publicise it so that other programmers wouldn't make the same mistake. (Perhaps we could hire Osame bin Laden to organize this task. Then he'd be socially useful.) | Does it mean that I can include anything I like in the combined | editor/printer/player I'm working on and if anyone doesn't like it Nyah, | Nyah! So there! ;-) ? Well, of course, you can. 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. ;-) | (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. There are a lot of people using non-Microsoft systems here. Some of us even use (gasp!) Open Source software. If you tell us anything about what your code does or how it works, you could be prosecuted. Go read your license. Or better, give it to an IP lawyer and have him explain it to you. (Note that that does't end with a ;-). It's not funny. There's a very real possibility that communication between Microsoft developers and other programmers will soon be illegal in the USA. Of course, some Open Source developers would tell that this might be a Good Thing. And some Sun, Palm and Sony developers ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
