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

[dewar@cs.nyu.edu (Robert Dewar)]

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.

OK, that's reasonable, both approaches are certainly acceptable, and 
obviously have equivalent structure, it is a matter of aesthetics which
you prefer.

What seems peculiar to me is people who are SURE that the goto solution is
somehow less maintainable and less structured. That seems silly to me. I
have seen plenty of junk code which strenuously avoids gotos, and pleny
of very easily maintained nicely strcutured code that uses gotos.

Sure, we all know that gotos are generally to be avoided, like unchecked
conversion.

However, a rule that says NEVER EVER USE A GOTO is as silly as a rule
that says NEVER EVER USE UNCHECKED CONVERSION.

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.

Please be clear, I am not saying that anyone who completely avoids 
gotos is incompetenmt, not at all. I am saying that it is wrong to think
that it is appropriate to visit this absolute rule on competent
programmers.