26 Jan 2013

On being a Roman in Rome

When I was 12, I remember asking my dad’s friend whether he gets mixed up between VB, C and Java, all of which he used at work. He had replied saying, “No, you just have to spend enough time on all of them”. Many years later I find myself in a similar position, having spent the last few years writing significant amount of code in Python, Scala, Java, Groovy, Erlang, JavaScript and PHP. I don’t have a programming language fetish – I just found myself moving from one project to another at work and happened to learn a couple of them for my side projects.

To be truthful, the first few times I had to pick-up a new language, I was not particularly thrilled about moving outside my comfort zone. Wading through a new language and some unknown framework was pretty daunting. It slowed me down significantly, and as someone who likes to get things done, it was not pleasant struggling to remember how to express my logic in an alien language. Over time, I have become a lot better at quickly getting up-to-speed with new toolsets, and on hindsight, I’m glad that I have been able to create meaningful things with all these languages. I don’t profess to have mastered all of them, but every language that I have learned has opened my mind and challenged the way I approach programming.

Just as my dad’s friend said, I don’t get mixed up between all these languages in terms of their syntactical differences. When I write Python I indent and when I write Java I curly-brace. What is however difficult is writing idiomatic code in each language. Imagine creating a AbstractSingletonProxyFactoryBean class in Python. You don’t want to be that guy, especially when working in a team with experienced Python developers.

It’s not easy being a Roman in Rome, though. Inevitably, ideas and concepts from one language affects the way you think and they percolate into another. I have been writing lots of Java lately, and I did not realize until recently that I’m not writing what I have commonly observed to be idiomatic Java. Here are some quirks:

  • My classes tend to have lots of static methods. This is a direct consequence of too much functional programming. I definitely find programs that have less state simpler to reason about.
  • Business logic is hence sometimes encapsulated in such static methods, rather than through the use of proper models which contain both state and logic.
  • When I split a large static method into a bunch of smaller ones, I almost exclusively pass the arguments in a way that’s not unlike a continuation-passing style (which is how I write JavaScript).
  • For classes that serve merely as data containers, I make all their fields public rather than using getters and setters on private fields. In the same vein, I sometimes forget to declare private methods as private – too much Python.
  • When possible, I try to even avoid creating such data containers, and instead preferring the use of Maps and Lists.
  • Heavy use of finals, probably influenced by all those vals from Scala.

I have mixed feelings about some of the observations above. In many ways, they definitely have made my programs robust, but probably at the loss of some idiomaticity. To be fair, I also think that idiomatic Java code can be pretty idiotic so I hope that gets me some brownie points.

I general, I would like to follow what I will call the party rule. If someone else is hosting a party, I try to turn up in the correct dress code (so long it’s not ridiculous like wearing some abstract proxy factory bean). If it’s my party, I get to define how the classes shall be dressed.

You can follow me on Twitter right here.

Tagged with:

3 people have responded to this post.

Leave a Reply