fostel@ncsu.UUCP (09/15/83)
Well, I think the use of the term "flaw" chart was clear, consise and
hard to mis-understand sarcasm. I can understand that some readers would
have trouble though. Some time ago on the net, I wrote a blatently
tongue-in-cheek item (on address spaces) and was mis-understood and
held up for ridicule (by another netter) for my ludicrous technical
opinions. A subsequent item introduced itself with the declaration
"BEGIN Joke", and of course then failed to use "ekoJ NIGEB". Now,
this is not a Joke: I really think the problem lies with the readers
as much or more so than the writers. Its a sad commentary on the
linguistic skills of our readership (and writership) that we need to
use formal techniques to identify humor and any but blunt expository
form. Funny how all the writers over the centuries have managed to
convey wit embedded in the writing without red flags to help out the
reader when a bit-o-wit is comming. Hang your heads in shame net-land.
----
On the same subject, someone criticsed the use of flow charts as being
low level, compared to wonderful C. Now, I know it is possible that
that was a joke. But I fear it was not. Flow charts do indeed contain
gotos, but they do it via a 2-d medium which allows it to work out very
nicely with a bit of care. I think that most flow charters in the world
do it very poorly, and this has lead to a number of "structured" flow
chart methodologies, such as HIPO charts. As with all the other modern
techniques, this is successful in direct proportion to the skill of the
user, not the qualities of the methodology. Proper use of visual design
and documentation aids is one of the more serious problems in our industry
(right after inability to read or write english witisisms) and SHOULD
be receiving serious attention from us. These funny devices we all use
to generate 95% of our technical material have a strong bias against any
non-linguistic constructs. TWe should try to rise above the limitations
of the medium. When Fortran was ugly we didn't abandon programming langs
we tried to make them better. Flaw charts tend to be ugly to -- so we
should try to figure out why, and how to do it better. Pict. worth 1000 ...
----GaryFostel----dgary@ecsvax.UUCP (09/15/83)
First, RE people misreading jokes: I've had the same problem many times. What I think is obviously intended in jest is taken seriously by someone. I'm reminded of all the soap-opera villains who get assaulted in the supermarket by some poor soul who can't tell tv from reality... Anyway, on flaw charts: I submitted a piece yesterday attacking flow charts as planning tools. Many instructors tell students one should always do a flowchart before starting a program. I have never met a competent programmer who found flowcharts useful as a planning tool, and I contend that the reason for this is that flowcharts are a very low-level "language", and that it takes much longer to do a flowchart for a given piece of code than to write the same construct in a higher level language like C, PL/I, or even BASIC. The example I gave was a fragment of C code that can be written as fast as one can type. The analogous flaw chart would take a minute or two to draw, and that's crazy. Now someone posts an article saying that flowcharts are useful for documentation, and implying I'm a C bigot. (I use C because it's the best thing available to me. I nevertheless consider it to be a poor language compared to what I'd like to have, which is a sort of rationalized hybrid of C, PL/I, Modula-2, APL, and Esperanto.) Well, doggone it, I SPECIFICALLY SAID that flowcharts are an excellent DOCUMENTATION tool. It's the PLANNING they're worthless for. Sorry to shout, but sheesh....