Fri 17 Feb 2006
I’ve been away in Ruby land for a while, and now that I’m doing (a little) bit of Java at my job, I find it so infuriating. For example, we have a logger class that I can call like so:
- log.debug("foo");
Fine and dandy. But say I want to output whether something is true or false, like whether something is null. My instinct (Ruby-encouraged) is to do this:
- log.debug(foo != null);
“Oh no”, says the compiler, “you can’t do that! That’s a boolean! I need a string!”
$&^!@&^%#@(
Frickin’ Java! Just turn it into a string! Call its toString method. Holy crap do some work for me! The other problem I have is with null. This thing is a special beast in Java. Doing something like this will yield a spectacular failure:
So I have to check whether something is null before I convert it to a string. This gets real ugly real fast:
Except that I don’t even think this’ll work because Java (maybe, I can’t remember) evaluates both parts of the ? : construct. So we’re left with this:
Jeez! Took long enough. Here it is in Ruby:
- foo = nil
- print foo
Ruby, my terse friend, you are just great! Duck typing is the future!
February 5th, 2007 at 08.52
Coming from a VB background, I’ll agree that strong typing results in more verbose code, but if you work on very large applications it can be helpful.
For example, null reference exceptions are not fun, but I’d rather have my program fail spectacularly when I forget to initialize a variable instead of silently propagating the null until it causes some undefined bad behavior.
Also, I’ve hit plenty of errors where I accidently stored a variable as the wrong type thanks to “helpful” type coercions.
If you spend a lot more time maintaining existing code rather than writing new code, I think its a fair tradeoff to safer but more verbose code. Having come from dynamically typed code, I know static typing has saved me more headaches than it causes.