Tables, nearly Code-Free State Machines, and future Requirements Compilation
Once upon a time (early 1980s), there was a coding contest to see how much functionality could be crammed into one line of BASIC code; limited to about 240 characters. I arrived at a way to have a one line 'engine', and then as many subsequent DATA statements as you wish. With the extra DATA lines, it wasn't really a 'One Liner' winner, oh well.
Each DATA statement was conceptually a row in a table, and each row effectively encoded a machine 'state'. The data elements were: State ID#, assigned action or output data, then an extensible list of condition values with their next state ID#. The program inputs caused the engine to jump around the table based on those inputs, as designed and listed in the table.
Essentially all the states of the machine would be coded into a big dumb table, and the actual code was simply a very tight little loop.
It's a powerful concept, in applicable circumstances. Put your machine states into a trivial table format, automatically transcribe it in, and then add the one line engine. Done.
The same thing could be done in assembler. A wee tiny bit of actual code, and then a huge table making it sing. The big silly table could be prepared in MS-Excel, even by a manager.
It's a small step from the above concept to that (soon to be here) future of Requirements Compilation directly into code. Spec writers become coders.
This sort of Table Driven State Machine coding method is very nearly code free. In case that helps.
Biting the hand that feeds IT
