2008-09-28

CLIPS is not a Lisp

In a recent thread on JBoss Drools' Rules Users mailing list, Mark Proctor writes:

... The Drools DRL language itself was designed as a more intuitive and less verbose language, this becomes increasinly important as you start to add more complex syntax which becomes harder to read with a lisp approach. I think most people in here would agree that the Drools DRL approach is an improvement over the lisp approach of clips/jess - apart from the die hard lisp fans.
I might be a die hard Lisp fan, but if you ask me, the problem is not that CLIPS (and Jess) are Lisp-like it's that they are Lisp-like.

CLIPS doesn't use a Lisp approach. It might look that way, but the similarities are only skin-deep. CLIPS lack one of the most fundamental requirements for being Lispy, namely, code as data. It lacks other things as well, but given that capacity (or in other words to be able to provide a higher level syntactical abstraction on top of CLIPS) there would be nothing wrong with CLIPS syntax that couldn't be fixed with CLIPS syntax. Yes. I know about build and eval but they'll only take you so far. It's not that I'm unhappy with CLIPS, but I honestly believe a Lisp-based CLIPS would be so much better.

My apologies to Mark. This rant has nothing to do with JBoss Drools. It's just that his post had the magic words in it ;-)

14 kommentarer:

woolfel sa...

The main issue I see with DRL, BLaze SRL and JRules syntax is that it still looks like imperative languages, which ends up encouraging developers to think that way.

Writing good rules requires thinking declaratively in a relational manner. There's a hypothesis from Sapir-whorf "language creates thought."

If the syntax looks and sounds like OO or imperative language, users will continue to think that way. From first hand experience, many developers (junior and senior) have a hard time with S-expression languages and never make that leap. The end result is they miss a fundamental and crucial part of rule programming. The thought process of the developer needs change if they want to be effective with rules.

I'm willing to bet good money that 75% of the developers out there using business rule engines (be it Blaze, JRules, Drools or MS BRE) don't get it. In those situations, my bias take is use decision tables, decision trees or hard coded rules instead.

On the other side, the BRE community needs to make it easier to understand rule programming. For the most part, it's still very difficult for senior developers to understand, so it's not easy.

woolfel sa...

I posted a blog entry pointing out the flaws of marks' argument.

Johan Lindberg sa...

I posted a blog entry pointing out the flaws of marks' argument.

Oh dear!

Johan Lindberg sa...

Hi Peter,

If the syntax looks and sounds like OO or imperative language, users will continue to think that way. From first hand experience, many developers (junior and senior) have a hard time with S-expression languages and never make that leap. The end result is they miss a fundamental and crucial part of rule programming. The thought process of the developer needs change if they want to be effective with rules.

Yeah, I guess you're right but I also think that Drools wouldn't have been as popular as it is today had they chosen an s-expressions based language. And CLIPS probably wouldn't have been what it is today if they had decided to base it on a 1980s Lisp implementation instead of the fastest language around.

woolfel sa...

I agree. If drools had chosen a s-expression language, my guess is it wouldn't be as popular. It is a trade-off. The part I don't like is claiming DRL is better, which that is purely subjective. for someone that just wants to externalize a few rules, DRL is probably going to be the easiest approach. that's fair, since they don't care or want to spend years learning about AI or logic programming.

a pure LISP approach would be much more flexible than CLIPS, but that introduces complexity. Perhaps one day things will advance to the point where that's possible.

Johan Lindberg sa...

a pure LISP approach would be much more flexible than CLIPS, but that introduces complexity.

Indeed. I can't see any benefit to start adding bits and pieces of Lisp infrastructure to CLIPS, but that doesn't stop me from wishing Lisa was more like CLIPS ;-)

There's also a difference in the scope of a BRMS (such as JBoss Drools) which expands to include more and more stuff (for example CEP) and a Production System (such as CLIPS) which basically has the same scope now as it had 10 years ago.

There's no need to add syntax to CLIPS but a BRMS using CLIPS syntax would have to have a way of handling these issues when, for example, adding support for CEP or whatever and if you care about backwards compatibility you might find you've painted yourself into a corner... which, if CLIPS had been a Lisp, wouldn't have had to happen.

But, like I said, if they'd chosen *that* way in 1985 things would have looked very differently now anyway. CLIPS would probably not have had the "position" it has today and we probably wouldn't have this discussion in the first place ;-)

woolfel sa...

I know a few of the guys that worked at ART and have had discussions about why they chose lisp-like syntax without going full lisp. I don't remember all the reasons, but there was a clear rationale for it. I'll try to ask paul haley and see if he remembers.

woolfel sa...

I sent paul haley an email. Hopefully he isn't too busy and has time to respond :)

Mark Proctor sa...

That's the thing, you are doing Lisp, without any of the advantages of macro programming, or code as data etc - so makes you think, what's the point, other than you like s-expressions.

Yes it's definitely objective, to someone with an s-expression background it's going to be easier, their mind will be trained for reading this - thus they will be more productive.

To someone not from an s-expression background, like the bulk of programmers. They are going to find DRL easier, that is the market we are aiming for, not hard core logiticians - who will always find prolog/lisp easier as that's what they have been doing for 15 years. The whole point in DRL is to chose a syntax that makes a rule engine accessible to the largest possible audience, with no drawbacks.

As ernest has found s-expressions is not ideal for complex constraints either, so he's done his nice {...} extensions for infix notation.

So while it is objective and it does depend on which one you are most familiar with, it is possible to get more concise and less verbose syntax when you break away from s-expressions - as ernest is proving, and drools DRL proves.

woolfel sa...

I could be wrong, but the reason why ernest finally decided to add support for those new features is because users kept asking. For those unaware of it, people have been asking for that since before 1998.

Generally, it's new users that ask for those features. Those users are often the ones who ask really stupid questions and generally don't get rule programming. A common example is they write long procedures rules, until people politely show them how to take advantage of rule chaining. Often, half of the people asking for those features never make the leap. To me, catering to those people is pointless :)

I'm totally bias. Those developers need to suck it up and take time to learn things properly. of course reality rare makes that possible, with tight deadlines.

Ernest recently encountered backward compatability issues with the new dot notation feature, so quite honestly it's not an advantage. I'm of the opinion it's a slippery slope. I can understand why ernest gave in and added the feature. You'll see from these threads on jess mailing list the feature isn't without headaches.

http://www.mail-archive.com/jess-users@sandia.gov/msg09957.html

http://www.mail-archive.com/jess-users@sandia.gov/msg10365.html

Like I said, S-expression changes how one thinks, which helps developers change the way they think. A java-like language does not encourage users change their thinking and only encourages people to be lazy. It's a matter of preference, but language does create thought.

Mark Proctor sa...

"I could be wrong, but the reason why ernest finally decided to add support for those new features is because users kept asking. For those unaware of it, people have been asking for that since before 1998."

Yup you are wrong, Ernest told mic and myself in person in BRF Washington that he would like to move away from Clips notation, but had a large group of legacy users that wouldn't want to do this. Ernest's {....} approach to introduce infix notation and direct field accessors is a fantastic compromise in this respect.

woolfel sa...

I guess after all those years of people whining and moaning, he finally gave in or changed his mind. If you look at the jess mailing history going as far back as 2002, his opinion on it was different.

I can understand why he gave in. I would have gotten tired of newbies bitching for 15 years too.

In one of the old interviews jason morris did with ernest, he also said if he had to do it all over again, he wouldn't have chosen java. Ernest is right that many old timers resist the change, that's cuz it's a questionable feature.

Ernest has every right to evolve JESS as he sees fit. After all, he is a one man army and wrote an awesome engine all by himself.

woolfel sa...

On a related note, when Oracle bought a license of JESS, they changed the rule language so that it's Java-like. I suspect that had something to do with it also.

woolfel sa...

I don't know if you looked at the link I provided, but it's far from elegant and has caused significant problems for atleast one user.

the dot notation goes counter to LISP and CLIPS. If ernest really wanted to change, then the better solution in my mind is to create a completely new language, not corrupt the existing one.