flowcharts and teaching programming / was Re: Barden programmingbooks
hilpert at cs.ubc.ca
Fri Feb 26 11:38:46 CST 2010
> Brent Hilpert wrote:
> > At the time, flowcharts were being deprecated in favor of "nested-block
> > diagrams" (for lack of any better description) to instil structured programming
> > concepts. Flowcharts had been deemed to be at odds with this. I had figured the
> > structure and limited complexity of the particular program was suitably
> > described by a flowchart. So much for judgement in choosing the appropriate tool.
> Be happy that INTERCAL is not your first programing language.
> > While I didn't see flowcharts much in the years after, I never saw a
> > "nested-block diagram" in real-world use.
> Just what is nested block diagram?
Amending my own description, "nested-box diagram" might be better. I wish I
could scan one of my old ones here.
Basically it's a bunch of nested boxes representing the block structure of the
program. Primary flow is down, if-else, for example, is two boxes side-by-side
within another box with the condition at the top.
Or one might describe it as a bunch of boxes drawn around block-structured
code, with some rules for how the boxes are nested and associated.
Very limited as the boxes quickly get too small as the nesting increases, worse
than when you actually write the program as you mention next.
> I have yet to figure out the advantage of nested block programs
> like pascal. You go down a few dozen levels - Oh crap I'm out
> of data space - abort!
Curiously, the exercise for which I was chastised for using a flowchart, was
written (by mandate) in FORTRAN. However, the nested-box diagrams which we were
expected to use had been introduced earlier in the course with, indeed, the
teaching of Pascal.
> You need that odd goto or unclean data
> structure now and then! Some times you need static variables
> just to know -- will I fit in memory on a realistic machine
> or have realistic run time?
When I was writing lots of C code in the 80's, I used goto's quite regularly (I
can hear the shrieks! and gasps! and jaws hitting the floor out there, or
perhaps not from this audience). I used them in a very obvious and formalised
manner however, for error handling and resource recovery/cleanup from nested
depths. It was much more understandable, reliable, elegant, and efficient than
multiple additional conditional clauses and variable tests which would have
obscured the primary algorithm and flow of the code.
More information about the cctalk