donn@hpfcrn.hp.com (Donn Terry) (02/04/90)
From: Donn Terry <donn@hpfcrn.hp.com> >From: randall@uvaarpa.virginia.edu (Randall Atkinson) >On an unrelated note, I will not find it acceptable or useful as a user >to have to change the names of the verious commands specified in 1003.2 >-- in particular Donn Terry's article leaves me with the impression >that the group has forgotten that those many of use who use these >tools interactively outside of shell scripts will find name changes >unacceptable. Yes I do use shell scripts from time to time, but >I use the commands alone at least as often and the committee needs >to treat that as a paramount consideration. Creating a standard that >won't be used is unproductive. First of all, in these situations there is a given: your system's behaivior (that you are used to) is different than someone else's system (that he is used to). If everyone agreed, there wouldn't be a need to change anything. Its only when two implementations disagree (and clash) that the problem even comes up. The choice is pretty binary: 1) Don't change the name: break scripts (and user habits) for some system. (Presume it would be yours, whatever it might be, at least part of the time.) Have loads of subtle bugs. 2) Do change them name: break everyone equally, but allow the vendor to leave all old code run. (And all your finger-macros would work too.) More important than anything else is to remember that choice 1 is guaranteed to cause exactly the problem you are concerned about, albeit at the option level, not at the command name level. Changing the name lets the vendor make you happy by providing an extension that is backwards compatible with your old habits. You don't have the problem you describe, presuming your vendor is at all sensitive to user needs. Donn Terry (As usual, whether I say it or not, these are just my opinions.) Volume-Number: Volume 18, Number 46
donn@hpfcrn.hp.com (Donn Terry) (02/04/90)
From: Donn Terry <donn@hpfcrn.hp.com> >From: tneff@bfmny0.uucp (Tom Neff) >In article <515@longway.TIC.COM> Donn Terry <donn@hpfcrn.hp.com> writes: >>I believe that standards encourage innovation. Clearly there are others >>who don't, and I'd like to suggest that they think about it again. >Standards purport to encourage innovation by providing a stable >consensus on which to build, but by nature they also had to bulldozer >PRIOR innovations to be born in the first place. The worry is that new >innovation, however "encouraged," will be similarly bulldozed when the >next standards committee comes around. >It is not EXISTING standards that exert a chilling effect on programming >creativity, but FUTURE ones. I can see the point. However, what would you suggest as an alterative? Every standard was once or will sometime be a future standard. Without standards we get chaos (as eveyone who has bealt with all the variants of UN*X knows). Donn Terry (Shooting off just his own mouth/fingers again.) Volume-Number: Volume 18, Number 45
tneff@bfmny0.uucp (Tom Neff) (02/05/90)
From: uunet!bfmny0!tneff (Tom Neff) In article <532@longway.TIC.COM> Donn Terry <donn@hpfcrn.hp.com> writes: >>It is not EXISTING standards that exert a chilling effect on programming >>creativity, but FUTURE ones. > >I can see the point. However, what would you suggest as an alterative? >Every standard was once or will sometime be a future standard. Without >standards we get chaos (as eveyone who has bealt with all the variants of >UN*X knows). 1. Don't standardize things the marketplace hasn't tested. 2. Don't wait a decade after the market DOES test it. 3. Don't take three years to issue the standard once you start. When these precepts are ignored, standards become an oppressive force, a drain on productivity, a laughingstock, or all three. Volume-Number: Volume 18, Number 48