the cost versus benefit definitely is an important consideration. In the past, I built custom languages for privacy rules and regulatory compliance rules, which are sufficiently narrow.
I definitely wouldn't attempt a DSL for general business rules. That will most likely result in a nightmare. peter On Wed, Jun 25, 2008 at 1:50 AM, Michael Smith <[EMAIL PROTECTED]> wrote: > > On Jun 24, 2008, at 8:53 AM, Peter Lin wrote: > >> I'm going to disagree that NRL is an anti-pattern. > > OK. > > >> It all depends on how you use it. > > Agreed... though since I having a tendency to be querolous, I'd > change "how" to "when". > > >> I've successfully designed and built custom business >> rule languages in the past. The key is keeping the domain well defined >> and narrow. > > I am tempted to envy you a bit here (in that the scope has been > defined and narrow enough to capture in a DSL, but "interesting" > enough to warrant an expert system shell). > > >> Don't try to make a DSL that is a general purpose >> language. > > Agreed. Unfortunately, it's been my experience that there is a > significant risk that a customer will drive DSLs inexorably towards a > general rule language. > > >> For example, say I want to create a rule language for defining privacy >> rules for mobile phones. > > ...<crisp example elided (nothing to quibble about) >... > > >> Once you have enough rules to get a good idea of the scope, you can >> start designing the language. > > Generally at the point the scope is clearly resolved in the projects > I'm thinking of, the bulk of the rules work has mostly been done. > The rules development coincided with exploring the subject domain > with one (or a handful) of experts. The maintenance of the rules > that followed been associated with a few experts at most, along with > a knowledge engineer, and at fairly low change rates. > > Changing the rules in a mobile phone privacy system or a message > routing system would seem to have a lot more rule-editing users, and > a more constrained capability than sendmail + scripting would still > be useful without a high risk of scope creep. > > >> Writing the parser is heavily dependent >> on how solid the DSL is. Once you have the parser, converting to JESS >> is straight forward. > > That seems reasonable. No argument that the parser -> Jess > conversion should be mechanical, if a good DSL can be designed. But > the effort requires enough users/usage to justify. > > Some rule patterns can even be simplified into fact assertions, meta- > rule to interpret them. OTOH, the problem has to be constrained very > well, or this approach can fail in a manner analogous to a overly > specific DSL. > > > Perhaps the key is that one must the problem well enough defined > before attempting to define a DSL. Analysis first, /then/ DSL > design decisions. > > - Mike > > > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
