does Jess language suck, or only its intro examples, or rules programming in general?

the intro example of Jess I am working through now is not only written in the LISP syntax (as if that’s not enough) but it also seems to specify the “variables v1, v2, v3, v4 have distinct values” constraint by using a long conjunction every time any of those variables is mentioned. E.g.

(pants-color (of Bob & ~?n) (is plaid & ?c3 & ~?c1 & ~?c2) )

This seems also to be a declaration of ?c3, or at least the first use of the variable - that just jumps out on the reader, right. I am not sure why they forgot to say that the color of his pants is also not ?c4 :rolleyes: but maybe c4 is not yet defined.

Anyway, so is this just a dumb intro example or is this wonderful language incapable of specifying a separate rule/constraint that says “c1 != c2 != c3 != c4”?

Some of these rules also look like they would look much prettier in an object oriented notation using equations. Sorta like

“Bob.pants-color = plaid” or maybe “Bob.pants-color = plaid | blue”

Then maybe we could start writing

“Bob.pants-color = plaid | Tom.jacket-color” - it just feels like a pretty natural notation

Anyway, so am I am on to something here in terms of uncovering the world’s inherent suckiness, or will all doubts be allayed by longer exposure to the cookbook recipes and suffering-induced Stockholm syndrome?

Or is that issue about specifying variable inequality in a more readable way going against some SAT-related complexity rule, and so we just have to do this way for the engine to be able to evaluate the rules?

And is Jess the state of the art as far as the discipline goes, or have they already built languages that look nicer?

Eh, everything that runs on the JVM blows. Just use Prolog like everybody else.

does Prolog not have these particular issues and is generally more user friendly?

I understand that Prolog does inference from results to the premises while Jess seems to be more of a decision tree from premises to results. Or at least that’s my dumb understanding of the backward/forward chaining at this point. Can you comment on the implications of that? Are real world applications for one and the other very different? Or can Prolog actually easily do forward chaining because maybe it is inherently easier than backward chaining?

ok here is some JRules sample code JRules Example - RIF . It looks prettier than Jess.

This book InfoWorld - Google Books claims that JRules is much more expensive and much easier to use than the cheaper and harder to use Jess. It does not go on to explain just how expensive are both packages. Or, just how expensive do you need to make a package to make it worthwhile to hire much smarter people to work with it.

This also makes me wonder if the difference between the 2 packages is or is not so profound as to be amenable to automated language translation, at least for some significant language subsets. Because if the answer is yes, it would make sense to make a tool that translates a dialect/subset of JRules into Jess and sell it to people who want to program in something like JRules but only want to pay for something like Jess.

First of all, Jess is based on a language called CLIPS, which is a C-language forward-chaining expert system shell. CLIPS has the LISP-like syntax. I imagine it does because the people who created it like LISP, but I don’t know for sure–I can ask some time. There is no reason that it should not have a Java-like syntax–it would be a simple enough project to write a parser that would translate a Java-like syntax into Jess.

Jess/CLIPS is forward-chaining, which leads to a significantly different coding style than Prolog, which is backward-chaining. I don’t know anything about JRules.

Jess/CLIPS is a great solution for problems that it works well with. In particular, once a program is working, it is easier to modify without breaking different parts–CLIPS programs tend to be weakly coupled.

I don’t really think that there is a large enough market for these programming languages to support tool *sales *of the sort you are talking about.

Reno Nevada, do you know why in the Jess intro example I have quoted above there is this ubiquitous specification that “this variable is distinct from another variable” that I pointed out in my OP? Clearly this way of writing these rules is a major deviation from how we think of these things in English. So is there a serious reason why the “values of variables v1…v4 are distinct” rule cannot be placed into a separate Jess rule or set of rules?

Or, maybe, it can be so placed but the book author did not feel like doing so?

I don’t know what example you are working on. If you posted a reference I could give a more complete answer. However, what I think you are looking at is the definition of a rule.

If that is the case, what you posted is a pattern that matches a fact with a certain set of qualifications. Variables can be used in a pattern; they are scoped for the rule, and so cannot be referenced outside of that rule. When the rule fires, the pattern will be matched against a particular fact in the database, and the variables will be bound to the fields of the fact in question. Variables do not have to be declared or typed before use in a rule.

In a Jess program, you do tend to see similar patterns appear in a lot of different rules. One of the biggest maintenance headaches is when you have several rules with similar but not identical patterns. Carefully documenting what the pattern is supposed to match (and not match) is very helpful.

Jess programs are not written like C and related programs, and there is a huge learning curve to adjust your mind to *thinking *rules-oriented programming.

As far as I know, Jess is “state of the art” for the particular art that it is, by the way.

Hope that helps.

The example is the one I quoted in OP:

I was being incensed by the fact that “variables c1 and c2 are distinct from c3” rule ended up encoded into this same rule.

If, as you say, Jess tends to produce wordy and repetitive patterns (perhaps what I am pointing out here is one such), could a higher level of abstraction be built on top of it to reduce this problem? Or would something like JRules be precisely that very higher level of abstraction?