Law of Averages

After reading a blog entry from Raganwald's delicious feed called Perfecting OO's Small Classes and Short Methods, I have some words to say. The author lists a number of exercises to force programmers out of a procedural groove and into a more object-oriented one.

This makes me wonder, is an object-oriented groove really a good one? In Java, you tend to write way more code than you really have to. Example:

//input a string from the keyboard
String input;
try{
    BufferedReader in = new BufferedReader(new FileReader(System.in));

    input = in.readLine();
}catch(Exception e){
}

Compare to Ruby:

input = gets

or even C++:

char input[1024];
cin.getline(input, 1024);

Something about the enforced "object-oriented" approach seems to me like there is more work to it than in a less object-oriented fashion. Don't get me wrong, using object-oriented techniques really saves you effort in many situations, but it is a diminishing return. If you try to program everything with an object-oriented style, you'll end up doing more work than you have to.

Let's move over to functional programming. This seems to be the latest craze among geeks nowadays, which means in 10 years it'll probably be big business. Best for young programmers like myself to get into it now.
It has some great advantages. For example, using map or reduce (in Ruby, inject) you can write some really good one liners:

#sum up the prices of our order
sum = shopping_cart.inject(0) { |total, item|
    total + (item.price * item.quantity)
}

compare it to PHP:

$sum = 0;
foreach ($shopping_cart as $item){
    $sum += $item->price * $item->quantity;
}

Not a lot longer, but shows a very different style of programming. For a trivial example there isn't a huge difference, but for more complex things the functional approach can be a lot nicer. Plus it scales really well, which probably explains why functional programming is a big thing nowadays, since scaling to multi-processing seems to be another big thing nowadays.

Functional programming also has it's disadvantages. Look back at the Ruby vs. PHP example. If you had never heard of inject/reduce before, would you have any clue what that did? Now compare it to this:

(define (roots a b c)
  (if (< (* b b) (* 4 a c))
      #f
      (list (/ (+ (- b)
                  (sqrt (- (* b b) (* 4 a c))))
               (* 2 a))
            (/ (- (- b)
                  (sqrt (- (* b b) (* 4 a c))))
               (* 2 a)))))

Do you have any clue what this is? To the educated eye (or the intelligent eye) you can probably figure out that this is the quadratic formula. Written in Scheme. While Scheme has a beauty in its simplicity, it is rather difficult to read.

Note that other functional languages like ML or Haskell are a lot easier to read than Scheme, but they have problems too. Attempt to learn them and you will probably see. Personally I don't see the appeal of Haskell with its "pure" functional approach. I'd say that mutable values are a great way to get things done, you don't have to spend time thinking "OK, how will I do this without changing any values, and still have the function tail recursive so that I don't run out of memory?"

What I'm thinking is take the good parts of everything. There are many good things about object-oriented programming (ever write a GUI app?), there are also many good things about other paradigms. Knowing the different paradigms will make you a better programmer, but using them alone will probably make you worse. It's good to see that the designers behind languages like Scala seem to have understood this. Now if I could just get Scala to work...