I have been trying to port Joe Gregorio’s Robaccia framework into Groovy in my spare time. Robaccia is written in Python and since Groovy was
inspired by Python (and Ruby), I wanted to see how easily Python code can be translated into Groovy. Plus, I now realize there is no better way to learn
new languages than trying to translate relatively non-trivial pieces of code from one to the other.

In general, I have been able to translate Robaccia code into Groovy without line creep. A method in Python 5 lines long translates to a Groovy method 5 lines long. There is this one situation I ran into, where I have not been able to find a good translation. Here is the line(s) of code :


parts = ["a=10"]
params = dict([tuple([s.strip() for s in param.split("=")])\
for param in parts ])


Run this and you will find that given a list of strings, the string “a=10″ gets munged into a dictionary with the key “a” and a value of “10″. As an aside, try this in Java and let me know how many lines it took. Seamless transitions between data structures are a very useful feature in a programming language.

This is the best I could come with in Groovy. If anyone has a better way, please let me know. For some reason, I think the Python code looks cooler.


parts = ["a=10"]
map = new HashMap()
parts.each { List list = it.split("="); map.put(list[0].trim(), list.size > 1 ? list[1].trim() : null)}


Recently read a book called Stumbling on Happiness. It is a well written book and contains descriptions of a number of interesting experiments that offer glimpses into how the brain works. To me, the title might have as well been Stumbling on Simplicity, I think we generally equate simplicity with happiness and complexity with “I need to get paid a lot of money to do this”. The assumption being that the money will make us happier.

Simplicity has to be one of the most subjective concepts. The book talks about how we are constantly making predictions of the future based
on sketchy notions of the past and a more accurate notion of the present. I think we find things to be simple, when these predictions are correct. When these predictions go wrong, we have to make an extra effort to understand something and we deem that complex.

So, the next time I want to re-use a piece of code, unless the person who wrote that code shared some of my experiences and “thinks like me”, I will find their code incomprehensible and complex. On the other hand, if my predictions about their code turn out to be accurate, the code receives a big two thumbs up and the stamp of simplicity. This is the problem with most software frameworks, my definitions of simple and complex are my own.

Unless I am a part of a statistically significant population, my definitions are worthless to others. So, here is the trick then – build a site like eHarmony,
call it frameworkharmony. Join in, fill in your software psychological profile
and we will find a matching framework. We guarantee that you will find
it simple and will code happily ever after.