I think that James Owens said: >Ernest would not say this. Read The Fabulous Manual.
To all Jess beginners (just to echo James)... I can definitely testify that other developer listservs are quick to point out the golden "RTFM/RTFD" rule... albeit with a slightly more Anglo-Saxon coloring. :-D Given the esoteric nature of rule-based expert systems development, I've really appreciated the patient tone that Dr. Friedman-Hill sets in fielding FAQs. However, there is a noticeable increase in the amount of listserv users who are attempting relatively complicated Jess applications without first having done their homework, and I can imagine him getting a bit frustrated in having to answer questions that he has taken great pains to answer elsewhere. Now, I have been seriously coding in Jess for two years, and only now do I feel relatively comfortable enough with the basics and the "Zen" of rule based-programming to build what'd consider commercial quality applications. Here are some newbie suggestions and observations that served me well in learning Jess: 1. Go to http://herzberg.ca.sandia.gov/jess/ and install the latest binary version of Jess (jess.jar) if you don't have it. Avoiding old versions avoids discussing already covered issues. 2. Study the online documentation at http://herzberg.ca.sandia.gov/jess/docs/61/ to get some background on Jess. 3. Make a short-cut reference to this Jess Functions link http://herzberg.ca.sandia.gov/jess/docs/61/function_index.html . You'll refer to it often. Put a link to the Jess API javadocs where you can reach them quickly as well. 4. Purchase a copy of "Jess In Action" by Jess's author, Dr. E. Friedman-Hill. This will be your main tutorial and primer on how to program in Jess. Its ISBIN code is 1930110898. Mine is "dog-eared" and annotated already from use. 5. Try the tutorials in the book and type the code samples into Jess so that you can see how they work. Experiment a lot. Change variables, modify patterns, add conditions, putz around until you get a feel for writing rules well. Avoid the performance traps of bad pattern ordering on you LHS of rules. Keep a programmer's journal for your notes. Reviewing a little CLIPS and some LISP won't kill you either -- mostly working with lists. Expert Systems:Principles and Programming by Giarratano & Riley is a good companion volume to JIA for this. 6. Join the Jess email list http://herzberg.ca.sandia.gov/jess/mailing_list.shtml . Don't be afraid to ask questions, but do try to exhaust the obvious causes of errors before posting -- you learn more that way. When I'm faced with that, I ask myself, "...what's Ernest going tell me?" and I dig deeper and usually find the answer on my own. The main things to keep in mind are: 1. Jess (and rule engines in general and the Rete engine in particular) are "data driven" (data are called "facts" in Jess), that is changes in facts drive the execution of your rules. 2. Rules are "opportunistic", that is they can (and should be allowed to) fire at any time when changes to the facts cause them to be "activated". Changes to facts occur every engine cycle, so rules that were inactive before may become active and those that were active may become deactivated. You shouldn't aim to control this heavy-handedly - it defeats the purpose of using rules. 3. Because of #2 above, some programmers have trouble grasping that the rule-engine actually controls the firing of rules, not the programmer. You specify "what" should cause them to fire, but not actually "when" they should fire. In other words, rule-based programming is not, in a strict sense, procedural or algorithmic -- it is not like the coding that you are probably used to in other high-level languages like C, C++, FORTRAN, or others (since even within objects, method code is still procedural and algorithmic, right?) That said, you can have some procedural programming in the rules themselves (typical looping and conditional branching statements for example). Take the time to learn a few of the proper ways to guide the control and flow of a rule-based program (goal-seeking, hill-climbing, using modules, using salience, using control patterns on LHS, etc.) 4. Rules have two parts to them: a left-hand side (LHS) and right-hand side (RHS). The LHS is strictly for matching fact patterns. Many error-causing implementations that Ernest is quick to admonish come from developers breaking this important principle. Jess has many different ways to group patterns - take a few days to study them and experiment a lot. The RHS is a list of actions to perform if the pattern(s) of the LHS is(are) satisfied. The actions are typically method calls. The great power of Jess is that the RHS can contain both calls to Jess methods, or given the proper references to other Java objects, it can call methods of objects external to Jess. Think critically for a minute on the flexibility that this gives your code. 5. Sometimes it helps to think of a rule-based program as a "state-machine", where the addition or subtraction of data (facts) from Jess's working memory moves the machine (your program) through different states. Your job as a rules programmer then is to figure out rules to transition between the states and what to do when a state is reached. 6. All other rules of good software engineering always apply to rule-based programming (think about architecture, goals, testing, modularized development, etc.) I hope that this helps you in your study. Jess is very cool technology, and it has actually improved my Java skills tremendously (gives me more of a reason to study Java!). Happy inferring! -JM ------------------------ Jason Morris Morris Technical Solutions [EMAIL PROTECTED] www.morristechnicalsolutions.com fax/phone: 503.692.1088 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
