Just Java 2007 Slides

As a reminder, I published the slides I used in my presentations at the Just Java 2007 conference in the Drools blog:

Just Java 2007 Slides (part I)
Just Java 2007 Slides (part II)

Enjoy, and feel free to join the community in our malling lists and IRC as detailed in the Drools Project site.

Quick catch-up and Language Orthogonality

It was a long time ago when I last posted to this blog, but I intend to fix that now. :)
Just a quick update, during that time I was very involved in finishing the features for the Drools 4.0 release that was released a couple of weeks ago. I am very glad with the result and we feel the current version is a great improvement over the 3.0 version released a bit more than a year ago.

Anyway, one of the major focus of the new release from a language perspective is the expressiveness of the language and it's learning curve. One of the ways of achieving that is improving language orthogonality. Today I found this article that besides short, gives to newcomers a good idea on what is language orthogonality and how it affects our life (as language users) every day.

Enjoy.

Wood Binary Calculator

I've been very busy finishing the release of Drools v4.0, so almost no time for posts, but wanted to do this quick one. A really cool wooden binary calculator.

The Reasoned Schemer

Just the other day I was reading Johan Lindberg's blog and I found this entry, talking about The Reasoned Schemer book. I confess I haven't heard about this book before, but the abstract of the book was so good that I had to buy it right away.

The book arrived last Thursday and I started to read it immediately. What I can say is:

• I haven't used functional programming in the last 10 years, since my graduation when I had a class about it in 1997. I almost forgot how fun it is to use it! I'm eager to skip to later chapters were it talks about relation programming, but I don't dare to do it... I'm really enjoying remembering all the stuff I learned in the past, plus learning new things I didn't know were possible.
• The book is written in a singular way, I haven't seen before. The whole book is a sequence of small questions, like small exercises, where the left column contains the question with eventual examples and the right column contains the answer. Each question intents to explain a new concept or improve the understanding of the previous concept/question. It means the book is slower to read, because it is dense! There is a lot of information to learn in each page and it makes you think while reading... it is not a mechanical reading process, it is almost an interactive learning. Very cool!
• The concepts of functional programming I am re-learning (or remembering) are making me think about some cool things it would be nice to have in Drools. Real unification is probably the top one, but I know the interest is more academical than corporate. Look at the following example (consider it pseudo syntax) from the book. It is a really really simple example in functional programming, but shows a simple trick you can do with unification. Imagine it leveraged for real inference problems.

(run* (l)
 (fresh (d x y w s)
   (cons w (a n s) s)
   (cdr l s)
   (car l x)
   (== b x)
   (cdr l d)
   (car d y)
   (== e y)
 )
)

Bold letters are constants and italic letters are variables. What is the value of l, after running it? If you said

( b e a n s )

You got it. If I were to chose a single line of the above example to show something most programming languages do not allow, but it is common for functional programming languages is: (cdr l s). It is the same as saying to the computer: X + 3 = 5 and having the computer tell you back that X is 2, without having to code any imperative procedure to solve the equation. Simple, but powerful.

Thank you Johan for pointing that out. Thank you to the authors for the fun time reading it. I guess I must buy the previous book now.

Human Computation and Fun Games

Yesterday I watched this Google Tech Presentation about Human Computation and was very impressed, both by the concept and the execution of the ideas.

Basically, the speaker talks about how to use "idle human brain cycles" for useful tasks, that computers can't do with current technology, while keeping people doing fun things. He called this relationship as a symbiotic relationship between human and computers. Really interesting.

I also was very surprised by the number of hours people spend with solitaire games: 9 billion hours in 2003?!?!

Oh God!

Oh god... am I like that? (don't answer!)


Which Programming Language are You?

Food for thought

Peter Lin is doing quite a few posts lately sharing his thoughts about temporal logic implementation in the last few days. Thank you Peter!

In this post, he makes a point in the AI x Business Rules scenarios and I agree with him. Although, the most fun is the AI side, the Business Rules side is the one that gets more practice and real use out there. Can we attend to both? :)

Anyway, he also talks about the retraction of facts from the network. The approach for doing it is not clear for me either, but I agree with him that the polling is complex and probably a waste of resources. I was thinking if it is possible to have a kind of registry, where facts registry themselves for removal at a specific time and this way we avoid the polling? Kind of what happens in simulation systems where the events are recorded in a time line in a way that the clock does not need to simulate every single instant in the time line... the clock can simply go from one event to other, since between events, there is no state change.

But that brings us to the most difficult design decision for me in the beginning of this research: how to model the clock?

Maybe Peter can blog about it? :)
Basically my thoughts and questions are:

* one can make the engine work with the either the real system clock or a pseudo clock implementation.

* using the real clock seems wrong to me, as the engine has no control over it. So if the engine is under a heavy load or must fire a lot of activations as a result of a given state, it may lose time windows and get inconsistent.

* using event's timestamps as the clock driver for temporal rules seems also no good for me because again, the engine has no control over arriving events (and it's clock). An example of problem with such approach is: what happens if events arrive out of order or from multiple, de-synchronized streams?

* so, the only option I feel it is feasible is to implement a pseudo clock over which the engine has full control. The user would still be able to constrain patterns of event's timestamps, since they are natural attributes of the facts, but the temporal behavior would be defined in relation to this pseudo clock. Question is: how does this pseudo clock gets "updated"? will the user explicitly call a "tick" method for each clock tick? will the engine somehow run the clock based on an external resource? I came to no conclusion so far and appreciate directions in case anyone already did something similar in the past.

Thinking out loud... ;)

Edson