26 Feb
2010
26 Feb
'10
9:38 a.m.
Ben wrote:
Brent Hilpert wrote:
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.
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? 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.