Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bbn!rochester!udel!princeton!phoenix!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: Control flow and common sense
Message-ID: <5110@pucc.Princeton.EDU>
Date: 3 May 88 01:02:15 GMT
References: <4605@ihlpf.ATT.COM>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 59
Disclaimer: Author bears full responsibility for contents of this article


In article <4605@ihlpf.ATT.COM>, warren@ihlpf.ATT.COM (Montgomery) writes:
 
>
>        2) Use an implementation that makes that control structure
>        explicit.  Implementing a finite state machine obscurely to
>        avoid gotos doesn't make the program more maintainable.
>
>--
>
     If you are not too concerned about efficiency, the best
     way to implement a finite state machine is as a two-dimensional
     table searched by old state and current symbol, yielding new
     state and perhaps some representation of an action to be carried
     out.  The neat thing is that your end users can check or even
     specify the table, and (if your project is sufficiently complex)
     the table can serve as the basis for tools that draw finite-state
     diagrams, check test coverage, or even produce automated documentation.
 
     I used this technique for a now-bought-out switch manufacturer
     that needed to simulate one of their PBXs using a Cobol program,
     running on the customer's mainframe, in order to produce accurate
     usage reports and bills.  The Cobol program had to be general,
     running on unpredictable machines.  It didn't have to be fast.
 
     My predecessor had written a GOTO-ridden monstrosity that was
     ridden with bugs and impossible to understand.  In
     the space of two months or so, a customer team and I collaborated
     on a table-based program that worked with every case that the
     customer could throw at it.  The tables were clearly demarcated in
     the program data division, such that the switch engineers and I
     could clearly communicate about how the PBX worked.
 
     Gotos could have been used to implement the finite state auto-
     maton, but this would have tempted maintenance people to add
     gotos outside of the table interpreter. I've seen a compiler
     generated using syntax-driven techniques where subsequent changes
     have obscured the designer's intent and changed the language
     compiled because the maintainers did not have any access to
     the syntax tables; this is a similar situation.  I'm not
     saying gotos are bad; the optimal and most maintainable method,
     IF you have cycles to burn, is a table interpreter.
 
     The technique was more popular when storage was expensive (Ref
     1), since a dense representation could be used for the table.
     However, Gerald Weinberg describes an incident (Ref 2) in compu-    s
     ting's early days when the method of table interpretation was used
     to increase quality and user/programmer communication.  Poor mana-
     gers, in this writer's experience, have always hated the technique,
     since it seems to cut them out of the user/programmer communication
     loop; good managers like it, because it almost always works well.
 
 
REFERENCES
 
1.  Brooks, Frederick R., THE MYTHICAL MAN-MONTH: Essays in Software
    Engineering.  Reading, MA, 1975: Addison-Wesley Publishing Company.
    Page 102.
 
2.  Weinberg, Gerald M., THE PSYCHOLOGY OF COMPUTER PROGRAMMING.  New
    York, NY, 1971: Van Nostrand Reinhold.  Page 17.