willCode4Beer

... Rule Engines ...

Declarative Programming and rule engines are closer to the way clients think.
True
Users know a solution when they see it. But, they don't necessarily know how to get there.
Given

Facts: represent current state of the system
Rules: represent knowledge
Backward chaining: can prove statements (think symbolic calculator)
    - goal driven reasoning
    - prove a rule is valid
    - does not need facts that are not required for proof

Forward chaining: execute rules (think expert systems)
    - fact driven reasoning
    - executes all rules that can with current facts
    - needs all avail facts

Performance issues may prevent usage of a rule engine in 'live' systems.

In the listing of "when to use a rule engine" he gives a case of:
     - "When you know the constraints of the solution, but now a precise algorithm to reach it."
Could I use genetic programming to extract an algorithm from the rule engine?
     - "When the algorithm is too complex, but a 'good enough' solution is acceptable"
A neural net is provided as a possible alternative here. He also points out the cost/time involved in properly training the net.
     - "When we have to deal with imprecise or incomplete input"
     - "When we suspect the solution will e a chain of exceptions and refinements to a generic rule"

When to avoid?
     - when there is a clear algorithm
     - critical performance
     - if the solution is unlikely to change (hahaha)

Next up, a basic example explaining the how the logic works in a rule engine.
Then a little comparison of Java source with CLIPS.
The example, sorting, is contrived but, its simple enough to get the point across. The normal java is simpler until, special cases are added. This is where the Java becomes more complex and the CLIPS code can stay elegant.

posted by willCode4Beer @ 10:36 AM