Call to Action

Webinar: Take a tour of Sparkling Logic's SMARTS Decision Manager Register Now

Rules Fest Live: Mark Proctor / Massively Parallel Hybrid Rule System


Written by: Carlos SerranoPublished on: Oct 12, 20107 comments
Mark Proctor

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.

Call to Action

SMARTS Decision ManagerSparkling Logic SMARTS is a decision management platform that empowers business analysts to define decisions using business rules and predictive models and deploy those decisions into an operational environment. SMARTS includes dashboard reporting that allows organizations to measure the quality of decisions both during development and post deployment. Learn more about how SMARTS can help your organization improve decisions.
© 2022 SparklingLogic. All Rights Reserved.