[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::languages

Title:Languages
Notice:Speaking In Tongues
Moderator:TLE::TOKLAS::FELDMAN
Created:Sat Jan 25 1986
Last Modified:Wed May 21 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:394
Total number of notes:2683

35.0. "Nassi-Schneiderman?" by XENON::STANSBURY () Thu Oct 04 1984 08:26

Has anyone heard of the Nassi-Schneiderman (is that spelled correctly?)
technique for programming? My wife's Pascal teacher mentioned it last night.
She said he was advocating it over the Von Neuman approach.

Who are (were?) Nassi and Schneiderman? What are N-S diagrams?

Jack
T.RTitleUserPersonal
Name
DateLines
35.1ELUDOM::FAIMANThu Oct 04 1984 14:4060
About 10-12 years ago, Nassi and Schneiderman introduced the idea of
"structured flowcharts", which are now sometimes referred to as
Nassi-Schneiderman diagrams.  Structured flowcharts are an alternative
to conventional flowcharts, which provide a more immediate graphical
representation of a structured program.  (The comparison to "von Neuman"
programming is nonsense.)

A typical N-S diagram might look something like this (Depth-First Search,
from Aho-Hopcroft-Ullman):

    procedure SEARCHB (v)
    +----------------------------------------------------------------------+
    |  mark v "old"                                                        |
    |  DFNUMBER[v] <- COUNT                                                |
    |  COUNT <- COUNT + 1                                                  |
    |  LOW[v] <- DFNUMBER[v]                                               |
    +----------------------------------------------------------------------+
    |  for each vertex w on L[v] do                                        |
    +        +-------------------------------------------------------------+
    |        |             \      is w marked "new" ?     /                |
    +        |               - - - - - - -+ - - - - - - -                  |
    |        |            YES             |                NO              |
    +        +----------------------------+--------------------------------+
    |        |  add <v,w> to T            |     \ is w = FATHER[v] ?  /    |
    |        |  FATHER[w] <- v            |       - - - - + - - - - -      |
    |        |  SEARCHB (w)               |         YES   |    NO          |
    |        +----------------------------+---------------+----------------+
    |        | is LOW[w] >= DFNUMBER[v] ? | LOW[v] <-     |                |
    |        | - - - - - - - + - - - - - -+  min(LOW[v],  |                |  
    |        |      YES      |      NO    |   DFNUMBER[w])|                |
    |        |---------------+------------+               |                |
    |        | a biconnected |            |               |                |
    |        | component has |            |               |                |
    |        | been found    |            |               |                |
    |        +---------------+------------+               |                |
    |        |  LOW[v] <- min(LOW[v],     |               |                |
    |        |                LOW[w])     |               |                |
    +--------+----------------------------+---------------+----------------+

As you can see, the diagrams are sort of pretty, and they are certainly easy
to read.  For diagramming structured programs, they are an enormous
improvement over conventional flowcharts.

I was originally very enthusiastic about them.  However, after some experience,
I came to the following conclusions:

	(1) (Minor)  They are a real pain to draw neatly, and the fact that all
	    the boxes are different sizes is inconvenient.

	(2) (Major)  The chart looks a lot like pseudo-code, doesn't it?
	    So if you're going to write pseudo-code, why not just write it,
	    instead of wasting your time trying to fit into boxes?  Well-
	    written, well-indented pseudo-code is just as readable as N-S
	    diagrams (well, almost -- the vertical columns for alternatives
	    may help a little), and much easier to write.

N-S diagrams were quite a successful attempt to develop a flow-charting
technique that would be appropriate for structured programming.  Unfortunately,
this is like trying to find the best place to mount a buggy-whip on a motor-
cycle.
35.2TURTLE::GILBERTFri Oct 05 1984 03:026
Wait!  It really is useful to learn the technique, even if it's unused, per se.

The current practice is to use standard flowcharts, with boxes (drawn with
dashed lines) to indicate loop constructs.  Whatever.  It's your flowchart --
although it may never actually be drawn -- so use whatever works best for you.
The N-S diagrams can be considered an aid in developing your own style.
35.3LATOUR::AMARTINSat Oct 06 1984 10:4619
Re .0:

I don't know who Schneiderman is, but someone named Nassi one worked for DEC.
Isaac Nassi is a reasearcher who was involved in the early stages of Common
Bliss, and also coauthored with A. Nico Habermann the first suggestion on how
to implement Ada tasking.

Re .1,.2:

Is N-S "just" a difference in notation, and perhaps some special hints on
how to use it to structure your thinking?  In contrast to something as
foreign as data-flow computation.

If so, that teacher made as much sense as a car buff saying "I prefer the
modern manuvering techniques taught in the Bob Bondurant driving school
instead of the more traditional four stroke Otto cycle gasoline engine".

Or is there something revolutionary in N-S that I am missing here?
				/AHM/THX
35.4BABEL::REAGANSat Oct 06 1984 18:053
N-S diagrams are also called "Nasty-Spiderman" diagrams....

	-John
35.5HARE::GILBERTSun Oct 07 1984 20:4716
Yes, it's the same Ike Nassi who worked for DEC.

A comparison with the Von Neumann model is mostly irrelevant; the instructor was
simply "snowing" the class.  The Von Neumann model has a single execution stream
for which actions are usually processed sequentially, and subroutines.  While
N-S diagrams can be easily extended to represent parallelism, the same is true
of a variety of notations.

Is there anything profound here?  N-S diagrams give flow-charts for the block-
structured and goto-free languages (which had already been advocated).  In the
encapsulation of loop constructs we see the beginnings of the fourth generation
languages.  Their "readability" is surprising, and suggests graphic programming
languages, as are now used for some data-flow and other languages.

As S.Clemens said in an introduction of "Mark Twain" (or was it D.Knuth in an
intruduction of "The Art of Computer Programming"?), "a tree is just a tree".
35.6NY1MM::SWEENEYMon Oct 08 1984 00:3216
Nassi and Schneiderman worked out N-S diagrams at the school where I got my BS
in 1974.  Nassi went from the State University of New York at Stony Brook to
DEC and worked on BLISS as pointed out earlier.  I've lost track of him but
assume he is still in the industry.  Stu Wecker and Peter Mierswa also went to
the same school. 

Ben Schniederman is the author of a lot of really, really good papers on
aspects of computer science such as software engineering and user interfaces.
He's a professor at some university. 

N-S diagrams are a good alternative to loop-oriented flowcharting, but its
rather dogmatic to teach it as a technique or stepping stone to good
programming.  Short modules, pretty indenting, etc are sufficient illumination
to show structure as well as N-S diagrams. 

Pat Sweeney 
35.7SAUTER::SAUTERMon Oct 08 1984 09:314
re: .4--It was Reagan who made the remark about trees, while he was 
Governor of California.  I think it was "once you've seen one tree, you've 
seen them all".
    John Sauter
35.8VAXUUM::DYERTue Oct 09 1984 10:472
	Right.  And it was Freud who said "sometimes a cigar is just a cigar."
		<_Jym_>
35.9WEBSTR::BEYERTue Oct 09 1984 12:083
But a good woman is a smoke.

	HRB