rokicki@neon.Stanford.EDU (Tomas G. Rokicki) (05/07/91)
Interesting comments, Glenn. > Imagine two carpenters building a door. One builds the frame, the other > builds the door. Neither one is on-site, and neither has met the other. > They are both working from the "spec", or the blueprint. How likely > do you think it is that the door fits in the frame, that the latch lands > squarely in the hole in the door frame, and that the hinges are set > properly? I wouldn't give it 1 chance in 100,000, even with experienced > carpenters. If I hired two carpenters, and gave them this task, and either one of them couldn't perform, I'd fire that one and find another. I expect quality carpentry, and I expect quality PostScript. But, the whole point is that this is something that we want to, indeed must, get working. Hence that spec had better be good, and the ability to test against the spec is essential. If we are going to push structuring conventions with the attitude that it might work sort of if we follow these rules, we'll be lucky to get anything working ever. Rather, we are obligated to - Formulate rules that, if followed, will always `work'. This is not the case yet, but we may not be that far off the mark. - Enforce those rules with testing procedures and compatibility suites. This is such a simple step that it is a pity that it hasn't been taken. Maybe I'll take some time off this summer and put together a PostScript test suite.