Re: State machines and Goto's (was Re: Should internet support software be written in Ada?)

[cons116@twain.oit.umass.edu (Mike White)]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: OK, I promised myself not to get into this silly goto discussion (having
: already gone around in it once on comp.lang.cobol).

: Here is the basic issue with finite state machines. A normal picture
: of a finite state machine is a spaghetti diagram with circles for
: states and arrows for transitions.

: Little gobs of code for the circles, and gotos for the arrows, is a very
: natural representation. it has exactly the same structure as the original
: pictorial diagram.

: For me, the case statement is just a little removed from the motivating
: diagram, so I find the goto structure clearer. I have often taken polls
: on this issue in my graduate classes, and I usually find the class divided.

The goto structure certainly reflects the FSM diagram in an intuitive
manner.  However, many of us simply loathe using it - I haven't used
a goto in a program since I last used BASIC: probably 6 or 7 years ago.
It HAS been ingrained in all coursework I have had.

One possibility for making the case structure more reflective of the
machine it is based on is by having a procedure something like

GoFromStateToState (current_state, state_of_bliss)

or even a function like

current_state = GotoState (state_of_bliss)

which simply sets the value of current_state to state_of_bliss.  This
does not change the fact that it is still a case structure,
but it might make the code more closely model, at least for a
maintainer, the FSM it is implementing.

[cut]

: People like simple rules. Some programmers are so incompetent that they
: can only be trusted to work under simple absolute rules. My rule is
: also simple: get rid of incompetent programmers.

This almost sounds like a typical argument against Ada from the C
people!  :)  (The part about sticking to the rules, not programmer
competence...)

Adhering to fairly simple rules is, IMO, essential for maintainability.
They should not be absolute, but nearly, as most problems _can_ be
solved without using tricks and without making the code particularly
contrived.  As I see it, the ability to find elegant solutions while
adhering to fairly strict rules is what defines a competent programmer.
--
***************************************************************************
*  Michael White 	        *  "Man is a biped without feathers."     *
*  cons116@titan.ucs.umass.edu  *				  -Plato  * 
***************************************************************************