Tom Benedict mentioned in passing that a "rule engine" he presented at the Summit in 2014 might be the right tool to help John Foster solve a problem. My ears perked up because I've long wanted to have a rule engine in 4D but haven't taken the time to write one. Tom hooked me up with the notes (I also have direct access @ 4D, as it turns out), and I wanted to make this resource visible to a wider range of people.
Rule engines are one of those specialized tools that it's good to know about in advance. Just like knowing about a specialized algorithm helps you solve a new problem, so too something like a broader technique - like a rule engine. Before getting into any CS stuff, let me link to an easier to understand example of a similar tool. In the life sciences, there's a handy tool called a "dichotomous key" that's broadly used. You have a bunch of yes-no questions that let you figure out what mushroom, weed, tree, whatever you're seeing. Graphically, it's a decision tree that looks like this: Dichotomous Key of Histology http://www.noelways.com/courses/Anatomy%20and%20Physiology%20I/Lectures_API/Lec4_Histology/Histology_Key/Dichotomous_key.html Normally, they're used as a series of yes-no questions, like this typical example: Common Trees of the Pacific Northwest https://oregonstate.edu/trees/dichotomous_key.html A silly one shows how it works with space aliens: https://au.pinterest.com/pin/574490496192985761/ The hard part with a dichotomous key is not using it, it's building it. You have to know enough about the subject to come up with the right questions. You need an expert. That's what the rules encode, expertise. Back in the 1980s, "Expert Systems" were kind of the rage. By chance, I lived with a DB2 programmer that was *obsessed* with expert systems. That's how I even know about them. But that kind of decision flow is a pretty old idea....an old Greek guy used it and figured out that humans are "featherless bipeds." Now, just for a moment, imagine how you would write a piece of code to answer the same question. Pretend that you've got a UI that lets a person describe a tree and figure out the species. What does the Pacific Northwest have? 50 native species? Something like that. (Since giant sheets of ice covered most of the region until recently, the soil there is rich but the species diversity is incredibly low.) Anyway, if you think it through - it's a pretty hard problem to solve. A bunch of keywords for different features? A bunch of fields for different aspects (general shape, color, shape of edge, etc.)? The searches are going to be hard either way. If you've ever found yourself in this sort of coding situation, it probably made your neck stiff ;-) Okay, so let's imagine that you sort it out - you've nailed it all down. Now they want to include exotic trees that are common in the area. Oh. So now you need to include gums from Australia, some Asian maples, and so on. Some fit pretty easily into your existing system as they're from families you already have (maples), others don't because they're from new families (eucalypts.) Okay, a pain, but doable. Now they want to be able to pick between versions. One with exotics, one without. Oh again. But your rules are likely baked into a bunch of complicated case statements and/or complicated queries. Not easy. In fact, when dealing with a real-world situation, it may literally be too hard to do. Just incredibly, deeply hard. Apart from that, with the codes implicitly encoded in fields/case of/search and combines, there isn't a way to reuse or visualize the data. Anyone that looked at the first link above saw a very easy to follow chart that encodes a *ton* of complex rules. You couldn't easily produce that by reusing anything pretty much hard-coded. So, that's bad. Rules embedded right in the code are hard to visualize, test, validate, reuse, modify, or even understand. It's a nightmare. Many of us have been there. So, this is where the rule engine comes in. You can to get the rules *out of the code and into data*. As data, the rules can be converted to a printed table for review, converted to a chart for reuse (like the first example post), duplicated and revised to make experiments or new applications easy. What do you need? Expertise Rules Rule processor Expertise is hard, of course. And for a real-world application, what you're probably encoding are complicated (read "insane") government regulations, convoluted pricing calculations, weighted prioritization factors (for scheduling or resource allocation), drug combination outcomes, dosing guidelines, or diagnostic guesses. Hey, those are all both complicated and important. Exactly the sort of coding you want to get right...exactly the sort of coding that's nearly impossible to get right with regular techniques. So back to Tom's tool and the three things you need. So, assuming that you are or have access to an expert, the coding parts you need are the encoded rules and the rule processor. Normally, that means a database + a language that excels at processing list structures. 4D isn't a great list processor language, but it can do it. Tom very cleverly leverages some XML+XSLT code that David Dancy (I miss him!) shared. XML is all about trees and XSLT is a tree-processing language. Nice! I wanted to post something about all of this because it's only due to an accident of personal history that I know anything about it. It's the sort of powerful, core technique that it would be very easy to spend a career never hearing about. There are TONS of database in the 4D world that can make use of this technique. If you have anything to do with medicine, check this idea out - it was largely made for you. (Seriously.) Hopefully Tom or someone else using this sort of tool can offer some real-world, 4D-based examples of how it's made their life better. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
