hydrovax@nmtsun.nmt.edu (M. Warner Losh) (03/15/88)
Stuff in [[]] applies to Fortran and S8 committee, the rest is a lesson learned from a software construction class. In article <1167@ut-emx.UUCP> reeder@ut-emx.UUCP (William P. Reeder) writes: >I just hate the idea of committees doing design work. I would like to >think that the vendors have a small number of folks doing design work, >most of the team being programmers who implement the design. There >are also researchers at universities doing design work. (Also >hopefully not by committee.) I tend to agree completely about individual vs. committee design, in general. Committees can work, but it usually is quite painful. I am currently a member of a class that is writing a program to help users manage a schedule. The students of the class were given some vague requirements from management [[ Gripes from Fortran User's ]]. We formed a committee of the whole and turned about a page of vague and nebulous features into over forty pages [[ The Fortran 8x's "proposed" standard ]]. Everybody (only fourteen of us, but that was more than enough) had their own favorite features to add to this program. Many features were nice to have. In fact all the features had a good reason for being present. However, they were not mutually additive, that is each added feature added a lot of work to the implementors (in this case also us). Also, the features didn't mix well, and strange and elaborate rules had to be developed to handle all of the bizarre cases we could think of. Just when we though we had it all nailed down, somebody would come up with some "small hole" that wasn't so small, and forced a rethink. After many of these rethinks, we decided that what we had couldn't get any better. [[ Fortran 8x released for public comment. ]] Then something weird happened. We had done some of the high level design (data flow diagrams, etc) and found more holes. [[ public comment, here the analogy might end. ]]. Instead of another rethink we did something worthwhile (thank you Brian and Pat), we took a HUGE AXE to the bloody thing. We chopped out the dead wood and unneeded, unasked for features. What resulted was a specification that provided what the user needs, and could reasonable want, but no more. Complex, overly general constructs were replaced with more concise and germane constructs. In short, the whole program was made more usable and implementable. I think that Fortran committee could learn from this example. There is a lot of good in the new Fortran, but there is also a lot of stuff that just doesn't fit in well with traditional Fortran, like the free-format source. Not that I'm flaming the idea of free formatting source code. I love 'C' for this very reason, but it isn't Fortran. Fortran has it's uses, although people are trying to make it all things to all people. Fortran is not Ada, nor has it ever pretend to be, until now. Fortran crunches numbers very well, at least compared to other HLL available today. I agree that many things are lacking in Fortran, but the committee's document is like hunting doves with large cannon. It is just too much change to an old language that can't really handle the change. As somebody said earlier in this newsgroup, the Fortran 8X committee should only add i) existing practice, where possible and ii) change CLEAR short commings in Fortran. All else should be scrapped with a large axe (or other suitable sharp object). Sorry for the length of this posting (emacs tells me it is seventy lines long), but I think that it is a good example for the Fortran 8X committee. -- bitnet: losh@nmt.csnet M. Warner Losh warner@hydrovax.nmt.csnet ! Don't know if this works, let me know. csnet: warner@hydrovax.nmt.edu uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax