Design to accommodate change: Table-driven programming [pdf]

This is just bad technical writing. He is unable or unwilling or simply too lazy to produce a single concrete real-world example of the object of his high praise. He says he has found applications ranging from real-time embedded systems to library loans, so how hard would it be for him to to give a simplified version of one of those applications as an example? Heck, I'll settle for a non-real-world example, as long as it's tangible and concrete.<p>Contrast this with Jonathan Edwards's presentation on schematic tables (a powerful generalization of state charts) which despite its somewhat academic feel makes a strong case to the reader by employing a significant non-trivial example--an example which is admittedly also elegantly solvable in a lazily evaluated language like Haskell, as I pointed out to Jonathan a while ago: <a href="http://alarmingdevelopment.org/?p=366" rel="nofollow">http://alarmingdevelopment.org/?p=366</a>

<i>Thinking Forth</i> by Leo Brodie has a good worked-out example of representing rule systems in various ways including several approaches that use tables. I think it's much better motivated than in the linked paper. Starting on page 52:<p><a href="http://books.google.com/books?id=1AlWbXItiCYC&#38;lpg=PA52&#38;dq=Thinking%20Forth%20%22defining%20the%20rules%22&#38;pg=PA52#v=onepage&#38;q=Thinking%20Forth%20%22defining%20the%20rules%22&#38;f=false" rel="nofollow">http://books.google.com/books?id=1AlWbXItiCYC&#38;lpg=PA52&#...</a><p>The entire text can be found here as a free PDF: <a href="http://thinking-forth.sourceforge.net/" rel="nofollow">http://thinking-forth.sourceforge.net/</a>

Hmm, I believe I've seen shades of this idea in Selenium's most basic test script format [1]. It isn't a decision table, per se, but it was designed to be as easy as possible for non-programmers to adjust. That said, I don't think table-driven programming is as widely useful as this author claims. Most of the testing engineers I know immediately moved away from Selenium script tables toward higher level constructs in JavaScript or Python. I don't think a table is great for expressing recursion or iteration.<p>[1] <a href="http://seleniumhq.org/docs/02_selenium_ide.html#test-suites" rel="nofollow">http://seleniumhq.org/docs/02_selenium_ide.html#test-suites</a>

I can give an anti-example of a table-driven system, although I am going to come right out and say that the table-driven aspect of this system has nothing to do with why it was such a problem. In reality, the project suffered from Conway’s Law: Its architecture was driven by the way in which management divided up the work of designing and implementing the system.<p><a href="http://weblog.raganwald.com/2008/02/mouse-trap.html" rel="nofollow">http://weblog.raganwald.com/2008/02/mouse-trap.html</a><p>tldr: Excel &#62;&#62; VBA &#62;&#62; XML &#62;&#62; XSLT &#62;&#62; Java!

I've used decision tables before and I don't particularly like them. The only good use for them is if the end-user both understands the rules and has the ability to change them. Otherwise, you're just covering up a code smell (nested if-else blocks) with a different representation without fixing the underlying problem.