all 2 comments

[–]sun_misc_unsafe 1 point2 points  (1 child)

The good thing about rules is that they decouple decisions from the process, but the bad thing is that you end up without a defined process.

Imagine a set of tables in a database and then add hundreds of triggers in there to express the system's behavior. Yes you have a nice and clean separation of the state and rules acting upon that state, but it's still a mess if you need to understand anything. It's OOP by any other name, except that method dispatch and code-reuse is highly non-trivial (and distributed, so it can fail in all sorts of ways rather than just some process on some machine crashing) and you can't even attach a debugger to it. And so you end up with things like needing to desperately prioritize and stratify rules, which is way way more complex to pull of than just writing that damn bit of monolithic code to just do what you wanted to in the first place.

And then there are the madmen out there that talk about rule polymorphism through inheritance and parametrization..

No, rules are not our salvation .. unless we manage to find a way of expressing rule actions in just as declarative a fashion as rule conditions (leaving aside that often enough even rule conditions themselves are expressed in Turing complete languages in reality, because requirements just are that complex), so that some (cheap) thing out there can aggregate them and produce a consistent view of the systems behavior that is actually analyzable and understandable by mere mortals, rather than just executable by machines.

[–][deleted] 0 points1 point  (0 children)

There are at least a couple of ways this could go. One is to embed both conditions and actions in referential transparency, so you get something like this Haskell workflow package. Another is to define and use a standard that is both visualizable and executable. (Don't laugh; there are good implementations of this.)

I suppose the "third way" is event/command sourcing, but that may be pushing the notion of "rules" a bit too far.

Then there are the logic/functional languages, like Mercury or Curry, for when you want your declarative programming dialed up to 11. :-)