Yo Richard et. al. You said-- Is it not true that a rules-based system (while even running the same rules and the same data) can have the facts (data) asserted in a different order ?? This could (possibly) lead to (the same) rules "triggering" in a different order. Is this not called "non-determinism" ?
I say-- NO. Same data, same rules, same engine, same result. State machine. Change the data, change the rules, change the engine and you might/probably will get a different result. For example, LEX and MEA do NOT fire the same rules necessarily and, ergo, will not reach the same conclusion necessarily. JRules is LEX while most others are MEA so you might or might not get the same result with a different engine. But, back to the original supposition (Same data, same rules, same engine) if you don't get the same result then you have a real problem. SDG jco -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Halsey Sent: Tuesday, October 07, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Aspects and rules (was RE: JESS: Jason Morris interview) Yo James. With respect to the part below: Another email is coming concerning that "procedural vs. declarative programming paradigm" part of this thread later today. Richard Halsey calls it "deterministic vs. non-deterministic" but I think that all computer programs are state machines (well, they ARE!) and that any program is deterministic such that with the same rules and the same data you get the same result, otherwise it would be chaos and I don't subscribe to the chaos theory. (Mostly because I don't understand it. :-) Is it not true that a rules-based system (while even running the same rules and the same data) can have the facts (data) asserted in a different order ?? This could (possibly) lead to (the same) rules "triggering" in a different order. Is this not called "non-determinism" ? A procedural (deterministic) system would probably march through the same procedures (in the same order) no matter how the data was presented. Of course, the data has to be presented in a usable fashion at the time of execution. With respect to AspectJ (and rules), I want to look at how certain "concerns" may be related simultaneously to different rule sets (via the conditional testing of a data relationship) and learn to apply the cross-cutting they speak of in AspectJ. Do we do it by the sequential execution of the different rule sets or do we do it by the joins/joinpoints of data ?? It may add yet another dimension to rules engineering that has not yet been addressed by the community. I don't think this is a "see spot run" problem. I be go back to sleep now ! Bubba ----- Original Message ----- From: "James Owen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 07, 2003 10:20 AM Subject: RE: Aspects and rules (was RE: JESS: Jason Morris interview) > "I stands all I can stands and I can't stands no more!" (Popeye the > Sailor Man) > > As most of you may (or may not) know, we have a fairly active Java > Metroplex User Group (http://www.JavaMUG.org) here in the DFW area. > One of our members (George Lawniczak)is totally sold on Aspect > Oriented Programming (AOP) and gave a two hour talk way back on August > 27th on the advantages and benefits of AOP. George is also a > MicroSoft Maven but, then, we all have our skeletons in the closet. > Some of the advantages that he covered were > > 1. Multiple Inheritance, even allowing the "dreaded diamond" effect 2. > Removing objects from scope or putting them into scope willy nilly 3. > The power to "not inherit" some attributes from a parent class 4. > Changing inheritance of a class from one to another 5. Making all or > some of the AOP advantages available to all members of the project 6. > Event-driven type programming, i.e., triggers 7. Dynamically have > classes/objects inherit or not inherit "on the fly" 8. Rules don't > care what happens outside of the rules. When we get the "stuff" it's > static. > > etc., etc., etc. One of the "selling features" of Java, originally, > was getting rid of multiple inheritance and moving it over, or up, to > an interface. An interface is, after all, a design concept rather > than a construction concept. (Thanks, Hafedh.) The other > "advantages" really went out into the Twilight Zone, taking over from > the basic Java compiler and saying that, from now on (for this > project) we will have thus and so, thereby putting these things in the > hand of all programmers on the project. > > On the positive side: On a small, tightly-coupled project, I could > see using that kind of power. Maybe. If we really needed it. On a > large project with lots of "newbies" all I could see was disaster and > mayhem. > > > Didn't we have lots of power with C/C++ programming? And wasn't it > really tough to get "newbies" to learn to code properly? After all, > most of us had to memorize Scott Meyers 85 rules (contained in two > books) in order to properly code a C++ project. Basically, AOP looks > like C/C++ Templates on steroids. And STL could REALLY mess up some > good C/C++ code in the hands of a renegade programmer. Admittedly, > Java took away a lot of the "power" that we enjoyed in C/C++ but it > also restored a certain degree of order. > > Another email is coming concerning that "procedural vs. declarative > programming paradigm" part of this thread later today. Richard Halsey > calls it "deterministic vs. non-deterministic" but I think that all > computer programs are state machines (well, they ARE!) and that any > program is deterministic such that with the same rules and the same > data you get the same result, otherwise it would be chaos and I don't > subscribe to the chaos theory. (Mostly because I don't understand it. > :-) > > Now, I've said all of this without reading a single book on the > subject, just the articles and the talk from George and reading some > of the information on the web. For example, here's an interview with > Gregor Kiczales. > > http://www.theserverside.com/events/videos/GregorKiczalesText/intervie > w. > jsp > > And here is link to Doctor Dobbs Journal with lots of articles, etc., > on AOP. You have to sign up to read the articles but there's no > charge. > > http://www.ddj.com/articles/2002/0208/ > > There's even a bi-annual DVD magazine devoted to AOP > > http://www.aspectmag.com/?OVRAW=AspectJ&OVKEY=aspect&OVMTC=standard > > enjoy... :-) > > SDG > jco > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Alan Moore > Sent: Wednesday, October 01, 2003 11:28 PM > To: '[EMAIL PROTECTED]' > Cc: [EMAIL PROTECTED] > Subject: Aspects and rules (was RE: JESS: Jason Morris interview) > > > Right on. Good interview - I like the bits about "back to the future" > ;-D > > Speaking of the future, I was lurking on aosd-discuss and the > discussion: > > http://aosd.net/pipermail/discuss/2003-August/000887.html > > was about event vs. aspect oriented programming and I posted asking > about how those compare to rule based programming. A paper by Filman > and Friedman (no relation?) was quoted as saying: > > Long quote from: http://ic.arc.nasa.gov/~filman/text/oif/aop-is.pdf > > "Rule-based systems like OPS-5[4] or, to a lesser extent, Prolog are > programming with purely dynamically quantified statements... If we all > programmed with rules, we wouldn't have AOP discussions. We would just > talk about how rules that expressed concerns X, Y, and Z could be > added to the original system, with some mention of the tricks involved > in getting those rules to run in the right order and to communicate > with each other. The base idea that other things could be going on > besides the main flow of control wouldn't be the least bit strange. > > But by and large, people don't program with rule-based systems... > They've destroyed the fundamental sequentially of almost everything. > The sequential, local, unitary style is really very good for > expressing most things. The cleverness of classical AOP is augmenting > conventional sequentially with quantification, rather than supplanting > it wholesale." > > R.E. Filman and D.P. Friedman, "Aspect-Oriented Programming is > Quantification and Obliviousness", Workshop on Advanced Separation of > Concerns, OOPSLA 2000, October 2000, Minneapolis. > > As it turns out, it isn't as hard as all that - especially with jess. > It appears that these are complimentary rather than conflicting > technologies. > > Aspects help create events or the aforementioned control structures > from which rules can reason. The noisy work of maintaining "computed" > value/state can also be lifted out the rules and data model and sliced > in via aspects leaving a cleaner rule set. Rule oblivious components > can be easily integrated via aspects - today. > > "What are you waiting for?" (tm) > > alan > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 01, 2003 6:18 PM > To: Jess Mailing List > Cc: [EMAIL PROTECTED] > Subject: JESS: Jason Morris interview > > > Hi all, > > Jason Morris has done an interview with me that he's prepping for > publication; you can see an excerpt along with a handsome photograph > of yours truly at http://www.morristechnicalsolutions.com/ . > > --------------------------------------------------------- > Ernest Friedman-Hill > Distributed Systems Research Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
