Delayed evaluation can be advantageous certainly for performance

“Fire rules” is a poor name in some contexts of course. More of a historic wording

Yeah, additionally my previous statements also glossed over: > There aren't any rules Clara doesn't make distinctions between rules and queries in the context of fire rules, they are both productions in the session and are treated in very similar ways.

I'm still figuring out "what is a rule engine good for"  My specific use case is for a complex ordering system, sort of like a restaurant.  Where a customer might order a "veggie burger" and I was thinking that the rule system could be used to build out the list of ingredients and compute their final cost and perhaps caloric impact.   And allow for variations, like extra mustard etc...   So my thought was the menu and its items would be the initial facts, and then the "orders" facts are mixed in - then the output is several detailed views (or queries)...  The bill, the ingredient list, the caloric breakdown.   Is this an appropriate hammer for this problem? In particular I like the way you can "audit" the outcome by looking at the detail of which rules fired and why. (For example, to see the extra pepers caused the price to change.)

I think a useful heuristic is: would this be hard to model without a rules engine?

Often these are problems that would involve lots of tangled nested conditional logic, and where the domain rules have sufficient inter-relatedness that they resist easy breakdown into simple components.

(For example, imagine modeling a tax code, where taking a certain deduction might result in adjustments to multiple computed figures, and might also mean that you can’t simultaneously take another deduction that you would otherwise be eligible for.)

If your ordering system has those kinds of rules, a rules engine might be a good fit.

Yea, I tend to think of a spreadsheet (although I use those rarely) but I think of the data cells as facts, and as some cells having forumula - rules.

I would think you could transform a spreadsheet into facts and rules.

It’s a good question to consider and it is often hard to articulate

I think rules engines were once were pushed heavily as a way to do business logic without needing developers. I think that perhaps had some success, but I think it is missing a lower level target that is valuable - and still can involve developers

It’s really this issue of how conditional logic can build up over time and become quite tangled. Let’s keep in mind that Clara puts emphasis on the truth maintenance system sort of approach to rules engines as well.

So it allows for a level of decoupling of conditional logic and making it potentially much less order sensitive (ie. declarative)

It can also “rebalance” efficiently if new facts come in over time.

And since it’s a structured way to somewhat declaratively represent this logic, you can fairly easily add automatic “auditing” (why facts were derived) structure over it in various ways. We’ve discussed this before a bit here with “supporting facts” or “contributing factors”

I have somewhat contrived example I used for this blog post (and associated clj/conj talk) years ago. http://www.metasimple.org/2017/02/28/clarifying-rules-engines.html I’ll share it since I at least attempted to make some “conditional” logic become tangled in a more traditional functional data-flow approach with no rules. Then showed how to rethink it via rules instead and examine the difference.

Agreed with the above. In terms of things many people would be familiar with, enn’s example of a tax code I think is a good one. There comes a point in the complexity of that kind of logic where expressing it with non-declarative approaches becomes quite challenging and IMO exponentially more difficult as new conditions are added. I informally think of a rules engine as being able to reduce such problems to “linear complexity” relative to the number of requirements.

“Linear complexity”. Nice. Good way to think of it.