Mark Proctor – using the most technology during the show (projection control, laser pointer, etc…) – focused on improving rule systems, in particular through combining technologies and making them massively parallel. Mark is a very passionate engineer – investing a lot of energy in Drools and making progress in engine technology. To start: “Rule engines suck. How can we make them suck less?”. Why do they suck in Mark’s opinion? – There are too many limits to the expressiveness of rules – It’s too difficult to control execution flow when it’s needed – There is too much ambiguity and complexity (things like infinite loops through data changes and rules firing, etc). He also added a number of things that I think have nothing to do with rules: transactions for example. Those are concerns that are in my opinion external to rules engines. He is talking essentially about production rule systems, of course. The examples he gives use the usual old-style notation that has not evolved – but only hard-core rules engine folks use that type of syntax and work at that level. You would expect me to react. I like Mark, but, come on, there were some of us doing some work in this space between the early guys and Drools, and we did do some good things. Stating that nothing has changed in the last 30 years is a good provocation artifact, but I think it is unfair. And I am also a programmer, I still program a lot. When we designed Blaze Advisor in the mid to late ’90s, it included a high level syntax (contrast SRL and the syntax used by other engines), included full support for execution flow control, function support, included support for open world hypothesis (support not just for “unknown” but also for “known”, “unavailable”, “available”, etc…), included forward chaining through Rete and opportunistic backward chaining, etc… The product also included formal static analysis – based on flow control and canonical representations – to identify not just firing cycles, but logic completeness and overlap issues, etc… It even ended up with multiple engines under a single framework – Rete, sequential, constraints, predictive model executor,… When we started selling Blaze Advisor, we sold it as an engine with an IDE – no server deployment, no repository, no templates, no business user interface – and we sold to technical people, lots of hardcore AI folks that we had to convince to pay a lot of money for rules engine technology. So, sorry, there has been a lot of progress, rewarded by significant market success, in engine technology. Of course there is space for improvement, but I wanted to make the point with respect to Mark’s flamboyant statement. I appreciate Mark’s motivation – keep improving the engine technology, but we can also do it by taking into account the progress that has been made. Going back to the presentation. Mark spent some time talking about the complexity introduced by salience based conflict resolution. Yes, that is a key problem in applications. His proposal is to use declarative logic to handle the cases in which there is conflict – this approach is similar in concept to what Soar does (as presented yesterday). He then made the parallel between rules and queries and gradually moved into an explanation on how functional programming concepts can enrich rules engine. This is the right direction, and one that is also taken by much more mainstream efforts, such as the group responsible for C# – witness the introduction of things like lambdas, closures, and cool things like LinQ. He finally spent time talking about some of the aspects in parallelizing engine execution and operating with sets (witness the work on MVCC). Both are important, and I do agree that changes in engine technology to properly address them is necessary and will introduce significant improvements, extending their applicability. For having looked at some of these things in the past, I can confirm that what Mark emphasizes in terms of implementation complexity is absolutely true – these are tough problems to crack properly. So… while I reacted to the reasons given on why current rule engines suck, I am glad that passion is going into making them better.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager