stanwyck@ihuxr.UUCP (09/13/83)
In David Gries book, "The Science of Programming", pp275-6, he refers to what I have always called a flow chart as a "flaw chart". He uses the term several times on the two pages, so it seems not to be a typo. My question then: Is that thing that demonstrates flow-of-control in a pictorial manner a FLOW chart or a FLAW chart? What is the origination of the term(s)? Who drew the first one, and what did that person call it? If it is a FLOW chart, why would Gries call it a FLAW chart without even a foot- note to the effect that this was his own term? Thanx for any info...... Don Stanwyck : 312-979-6667 : ihnp4!inuxr!stanwyck : bell labs @ naperville, il
stuart@rochester.UUCP (Stuart Friedberg) (09/14/83)
I believe he is trying to be funny. Flaw as in bug. Whether or not he is criticizing the (over)use of flow charts to the exclusion of reasoning or emphasizing that they help to find flaws, I can't say.
Pavel.pa@PARC-MAXC.ARPA@cornell.UUCP (Pavel.pa@PARC-MAXC.ARPA) (09/14/83)
From: Pavel.pa@PARC-MAXC.ARPA To: net-lang@CORNELL In-Reply-To: <8309132316.AA00638@GVAX.CORNELL> Take it from a student of David Gries: He calls them FLAW charts because he blieves that they are frequently a cause of flawed thinking about programs. The rest of the world calls them FLOW charts (unless they (properly) agree with David). Pavel Curtis Cornell University
dgary@ecsvax.UUCP (09/14/83)
One would suspect Gries is pulling someone's leg with the "flaw chart" spelling. I once had a computer science prof raise hell at me for telling his students that flow charts were worse than worthless as a planning tool (but quite OK for some documentation purposes, if they weren't too detailed). He finally shut up after I invoked the First Amendment. Anyway, I sought to explain my phlowchart phobia to him in the following manner: Flowcharts are a primitive form of language with two control structures: the conditional goto and the unconditional goto. This makes flowcharting pretty low level and procedure oriented. Those characteristics are precisely what we DON'T want in a planning language. Consider the following C fragment to count the characters in the standard input: while ((c=getchar()) != EOF) count++ ; Now, this is a fairly low-level statement in itself. It may look odd to a non-C user, but it's crytal clear to even a novice C programmer. Consider, on the other hand, the flow chart one would devise to "plan" this statement!! I repeat: flowcharts are useful for many purposes, including non- computer-specific statements of simple algorithms, diagrams of data flow, and the like. But as a PLANNING TOOL (where they often get the most support from amateur programming instructors), they are a disaster on the order of suggesting SAS programs be "planned" in assembler! D Gary (mildly opinionated) Grady (dgary) Duke User Services
mark@cbosgd.UUCP (09/15/83)
In my opinion, FL*W charts are useful for only one thing: Explaining to management what it is your program does. The reason they are useful for this is that any moron, no matter how inept or untrained, can understand a fl*w chart. Not to imply that all managers are morons, but many of them have little or no technical training or understanding of what's going on. (I do not prepare fl*wcharts for my current management, nor have I ever. But some people must.) It has been shown several times that fl*wcharts are worthless as a design aid. I believe there was a well done experimental human factors paper in CACM a couple years back, for instance.