On 11 Mar 2013, at 03:10, Grant Rettke <[email protected]> wrote: > On Thu, Mar 7, 2013 at 2:44 PM, Matteo Mortari <[email protected]> > wrote: >> The Question I'm asking myself: is there a specific, or few, areas where >> Functional Programming could actually benefit Expert Systems so much to >> actually spawn new paradigms of writing Rules? Or benefit in a new >> generation of the Rete algorithm? >> Or actually, Functional Programming will spawn a completely different >> paradigm of system which will go beyond Expert Systems the way are designed >> today? > > Great question, very inspiring just to think of the possibilities. The > biggest opportunity out there right now is for rules-engines to help > bridge the artificial gap that exists between the so called > fundamental models of computation for the different camps. For > example, Java is a Turing style sequential language and Lisp is a > Church style functional language. This shoe-horning of languages into > different camps is arbitrary, boring, mentally restrictive, totally > artificial, and offers little more benefits than easily separating > books on a bookshelf at the bookstore. It is really, really sad to see > the quelling of creativity and reduction of the beautiful parts of > different computational models reduced into tiny, little, lonely camps > that must live in isolation. Digging into rules engines is a pathway, > albeit deeply unpopular, into another important form computational > expression that never really got it's day in the sun like the biggies > today. +1 :)
I think the work in expert system tools is the only real paradigm shift going on. All others are just cross pollination of the same ideas. The downside is to get expert system tools to a level where we can compete easily, as a more general purpose tool, is very hard. Research expert system tools stopped in the mid 90s, due to the AI winter: http://blog.athico.com/2012/05/drools-54-artificial-intelligence.html We have plenty of ideas, the problem is in balancing trying to build a system suitable for production use - where people are conservative and don't like change - and a system which is constantly innovating. The other issue is in finding people willing to research these ideas with us. It's very easy for someone to get into scala or jruby or what ever and just start adding features. It's very hard in our case, because the change is too much, it's very hard for people to see how to apply what they already know to this new paradigm. For instance here is an idea I've been mulling over recently (note just random ideas, not roadmap). We don't have the resources to completely compete against other languages, and I'm not sure we should do. With Java8 and 9 it starts to become a more compelling language. Java8 brings lambs and java9 solve the perm gen issue (so we can stop using MVEL, and just go pure code generation and not worry about blowing the perm gen). Could we create a system that better layers with java9? We already want to drop dialects for DRL (it just makes things too hard to explain and write IDE tooling for). So the idea is to have a single language. This made me think of the Pizza language, which layered neatly ontop of java, and eventually became scala. http://pizzacompiler.sourceforge.net So thinking really long term here. Can we build a "java layer" that provide all the rule functionality we need - but fit ontop of the java language neatly. We'd probably need to allow "rule" keyword and have it in Classes, at the method level. All class members and methods would be available to the rules in that class. Can probably think of that containing class as a RuleModule. We'd have to rely on CDI and annotations for declarative wiring of member fields ( http://java.dzone.com/articles/cdi-di-p1). The biggest challenge would be in extending the java language to support LHS literals too (something I've wanted to do anyway) to provide LinQ style features, backed underneath by the Drools engine. A list of layered features might look like: 1) PropertyAccessors (doesn't look like java will ever add this, but DRL needs it to remain compact) 2) Type Inference (same as above, some argue that lack of contract design is a bad thing…..) 3) inline casts (needed for units, and keeps DRL compact) 4) "when" literals, like linq - but supports our entire LHS language. 5) rule keyword (similar at method level). We can use CDI to provide declarative injection of member variables. public class MyClass { @Inject public MyService service; // CDI injected service public void someMethod() { } rule xxx when { …. // normal LHS here. } then { service.call(…..) someMethod(); } } I won't cover LHS literals here, but look at reactive LinkQ, to get some ideas. There is a lot more to this idea of a layered language, and we can exploit annotations in all sorts of ways. Similar to my previous email on meta approach to building rule systems. We could use annotations to wire RuleModules to KnowledgeBases, and vice versa. One of the challenges of doing this layered option, is that the JDK is GPLd + linking exception. We'd even need to develop and maintain our own antlr+asm layer that does 100% of java9 + our extensions, or GPLd+linked exception Drools and extend the JDK. Mark > New and interesting things will benefit all camps when they dig > into the world of production systems and welcome it as a first class > citizen to their programming toolbox. Would it result in new and great > things? Who knows :). > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
