All You Need is Time

A lot seems to be happening on the front of persistence lately. The NoSql movement is gaining momentum as different businesses find out new ways to use schemaless databases not done in the paradigm of relational databases. Graph databases, document databases and object databases seem to be hip things currently.

And rightly so. In many cases relational database with it's rigid schemas requires way too much prediction in order not to become quickly problematic for implementing new-found needs. Another matter is the problematic clash between another prevalent paradigm, Object Orientation. OO and RDBMS simply don't match up too well. ORMs try to alleviate this problem with varying effects. Some of them do it very well, others less so. And anyhow even with the best ones the problem of two worlds colliding quite often shows up.

And into the fray enter Rich Hickey and Stuart Halloway of Clojure fame. Datomic, their take on databases is very different beast indeed. As could be expected their vision is very fresh and new. It separates several parts of the need for persistence into their own entities, solving many problems that many other contenders couldn't.

A post in Finnish language, published in the Siili blog seems to be on the cutting edge of Databases. In the post Matti P. Pulkkinen makes the notion that single very neglected part of information is the aspect of time. And many difficult needs of customers seem to have something to do with time.

Interestingly enough, one of the main ideas of Datomic is to take time as an essential aspect of a persistence layer. Instead of finding a place where memory resides and changing the memory itself, Datomic makes enters a new fact into the storage accompanied by notion of the point of time it was recorded.

If you think for example access control the idea seems extremely good. Instead of finding the place where we store whatever a person can access some resource and changing it, we can merely state that as of this moment he can access this resource. Or not access for that matter. If we ever need to see if this person has had for example "yesterday" access to some resource, we simply check it in same ways as we can check if he can do it today.

I haven't yet had time to try Datomic, but it seems very interesting indeed and certainly is on my list of things to try out.

There is one thing that people seem to forget. Persistence is just a "real world" need, not really functional one. And for some reason it seems to all too often find it's way to too much the core of things.

Cool Trick with Ruby

First of all i have to admit one thing that's pretty irrational. For no good reason whatsoever i have a slight personal dislike for Ruby. It's actually pretty strange even to me as i see many ideas in it. I haven't used it much and still i seem to be able to understand most of code I've seen written with it. And that's pretty much the only language of which I can say the same praise. And recently I've even found myself writing some short things in Ruby.

Even funnier is that my dislike is very irrationally mainly based on the fact that those @ and @@ seem to unaesthetically clutter the code. And still i like CoffeeScript very much.

Ok, now that I've mentioned my most secret and extremely silly prejudice out loud we can continue with my main point. Oh and feel free to try to talk me out of my prejudices.

In Haskell one of the things i like is the expressiveness of the syntax somehow it can make many things extremely clear. One of the features i do like is it's list comprehension. Very neat and extremely powerful.

What i found extremely amazing about ruby is that someone has been able to bend the language to understand similar syntax. Granted that the code is bending things not too nicely and that without laziness the list comprehension looses much of it's power, still this is a very good show of what Ruby is capable of.

A Paper that Had a Huge Effect on Me

When i first started to introduce myself to the wonderful world of Clojure reference to one particular paper seemed to pop up often. Out of the Tar Pit, by Ben Moseley and Peter Marks.

The paper examines the idea presented by Fred Brooks of splitting Complexity to two different types. Essential and Accidental. But the paper disagrees with Brooks's notion that most complexity in modern systems is essential. The paper states that while it is easy to create complex systems simple ones are much harder to create.

"Simplicity is Hard"-Out of the Tar Pit

The paper continues claiming that the only significant factor for making it hard to create software is Complexity. So it is essential to bring more simplicity to our design.

Main causes of complexity in software are presented as State and Control, with some more minor ones brought along. The paper claims that three important principles are behind these other causes.

1. Complexity breeds Complexity Complexity is created because the system is already too complex to be understood.
2. Simplicity is Hard Creating simplicity requires effort and in the short term it seems more viable. Simplicity can only be gained if it is prized and sough after
3. Power Corrupts Similarly as the power of managing memory manually creates problems removed by Garbage Collection other kinds of power create other kinds of complexity. The singles out the power of state (mutable) as one of the main causes of complexity

The paper continues by splitting state into essential and accidental and distinguishing into which types of state different kinds of data belong. The main point here is that the only essential data is the data coming from the user. After this a recommendations are given to separate different kinds of complexity and distinguishing useless Complexity in order to avoid it as well as representing a model on doing this separation.

Last parts of the paper discuss using relational model as a example of doing the mentioned recommendations.

All in all i don't think many other writings have had as much effect on my programming as this paper, although i look forward to encountering more of it's kind. Any recommendations?

Thinking Functionally

A biggest benefit of functional programming I've noticed in myself is how it has changed my thinking of programming in general. It has had a profound effect on how i do my code in other languages too.

This is not only reflected in the grumbling you can hear emitting from me when using less functional languages, but also winding ways to do things differently in for example Java. Avoiding unnecessary use of mutable state, using map and fold instead of iterations where applicable etc. Separating Essential Data from the functions that derive other data from it etc.

This has been a result of some time of using functional languages. But it doesn't mean that you need to use extensive amount of time with FP (tho i warmly do advice you to). For those of us who need a gentle intro to broaden their perspective, PragPub Magazine has a great article to bootstrap yourself with functional thinking.

Dabbling with Haskell

My interest on Haskell was raised while i was developing things on Clojure and heard the language mentioned often. Encountered mystical notions that simple side effects like writing to the screen needed some advanced mathematical concept called Monads. This naturally pecked my interest.

When i noticed that a book called Learn You a Haskell, by Miran Lipovača,  free on the net i decided to read through it. And i have to say it was a great introduction to the language. Reading the book lead to a brief usage of the language. Not for any real program but seeing what kind of solutions i could create for various small problems with it. So Basically just doing some Katas.

All in all i learned a lot. I i now say often that the way i learned the little i do understand of Scala is through first learning Java, then Clojure and finally some Haskell. I mean just reading the book and trying out a bit made me understand Scala a lot better.

So i decided to try writing some mall program with it, but have to admit that i'm way too much pampered by the semi automatic build tools of JVM and did not have time to delve into building a program for real.

Yesterday i found out another book on the Language free on the net. Real World Haskell, by Bryan O'Sullivan, Don Stewart, and John Goerzen. So maybe this time i could try out doing something more real with Haskell.

A view on joining OO and FP

I've done some work lately on CoffeeScript and Node.js. One question that frequently comes into mind in this environment is how to join OO and Functional paradigms.

The whole idea of asynchronous JavaScript of course presents a clear way to do a lot of stuff. Event based message passing system of Node.js makes a clear alternative for using anonymous function spaghetti in a traditional JavaScript way. And this raises again the question of how to join these two very different Paradigms.

Another place i have recently encountered one way to combine the power of these two ideas is the Microsoft LINQ. It presents a quite elegant way to enter queries to a OO program by using a combination of FP and OO techniques.

Today i read an interesting article on one way to resolve this. A blog post by Michael Feathers from march. In the Post Feather suggests that OO seems to be more about telling objects to do stuff. FP in contrast is about asking functions for something. He suggests that it might be a good idea to combine these on an System so that the upper most layers of the system are composed of objects that are told what to do and lower levels of functions that these Objects use. Sounds plausible, although i have to admit that the FP side of my soul is crying in pain on the idea of being bossed around by a bunch of mutable state entities...

What do you think?

Clojure in the Cloud

I really love the expressiveness of Clojure. It has the basic power of Lisp combined with the wast library available for JVM.

One thing i have been very interested in is to find great resources for hosting Clojure applications. Already some time ago i heard that Heroku was supporting clojure, but never had the time to try.

Yesterday i found on the net a blog post by James Ward on how to do this and it seems very straightforward. So maybe i'll have a good incentive to do more work on Clojure.

Now only thing i have to figure out is what to create...