26 Jan 2013
On being a Roman in Rome
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.
- 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.