[lutusp]

You really don't want to think of this in terms of IF ... THEN ... ELSE but as individual binary or multi-path choices. These are most efficiently handled with hash tables that choose a route through a logic diagram in a way that is more intuitive than If ... THEN ... ELSE as well as more efficient.

You start by writing a logic flowchart that you understand, then you reduce the logic flowchart to code, usually automatically. This is how a logic flowchart looks:

http://en.wikipedia.org/wiki/File:LampFlowchart.svg

Here is the article it appears in:

http://en.wikipedia.org/wiki/Flowchart

The single most important parts of this process are:

1. That you understand the logic diagram and see that it meets the program's requirements.

2. That there is a way to turn the logic flowchart into code, ideally without human intervention.

3. That the rebuild time be short between adding a new logical step and testing the resulting program.

[JoeAltmaier]

Maybe I'm off the mark, but whenever I see a long runon procedure full of if-then-else, I think "This is a job for a state machine!" With that approach, you can exhaustively provide actions for every combination of states and events. You can also immediately identify the code responsible for handling any state+event. You can also track which state+event transitions have been tested automatically.

[lutusp]

> Maybe I'm off the mark, but whenever I see a long runon procedure full of if-then-else, I think "This is a job for a state machine!"

I'm a big fan of state machines, but systems like this are often multitasking and (for all practical purposes) stateless. OTOH it might be more accurate to say their state is formally unpredictable.

A system like the one being described would be more like a multi-threaded critical-path flowchart, where multiple processes are active at a given time. And at any time a high-level linear programming result might mandate a change of strategy based on available resources, even though individual processes continued to follow the tactical flowchart.

So even though a state machine approach looks attractive (as it always does), it's a matter of deciding how many states and how many levels. Because of the nature of the original problem and the number of connections with everyday reality, the fact that it was a state machine might escape the attention of even a careful observer.

[prunebeads]

You're not, imho. The problem is : how do we manage the data associated with the structure of this gigantic state-machine. It is likely to change overtime, so it cannot be hard coded (although if it were, one could perhaps use a tool which compiles the state machine to hard code).

Basically, many of the solutions proposed are more or less specialized state machines (decision trees, markov chains, rete algorithm).