Skip to Content »

Tech Life of Recht » Thinking in Objects

 Thinking in Objects

  • April 16th, 2007
  • 9:35 pm

In relation to my post about UML, and my experiments with Haskell, I’ve realized that I jave a handicap, which I have no reason to believe isn’t also hindering a lot of other people.
I started programming quite a few years ago (on my grandmothers C64, actually, at about the age of 8). Of course, it was not methodical or anything, and it more or less remained unstructured until I started at university. One of the first things we learned was object oriented modeling with UML. I’ve talked a little about UML, but actually object orientation turns out to be a more fundamental problem.
Without any doubt, OO has helped me tremendously in the past, but I’ve realized that it’s also become a hindrance. Why? Quite simply because I can’t think of a problem without modeling it in OO terms. Some might see this as a force, which it probably is in some situations, but we live in times where language paradigms are getting mixed up – just look at Ruby and RoR, .NET 3.5 – and this means that us OO people might be getting a hard time utilizing the languages.
Of course, working with something like Haskell only makes it worse, as it contains no objects at all. There are some concepts which can be mapped, but programs are structured and modeled differently. The OO thinking has proved to me to be the biggest problem with learning Haskell. Learning a new syntax, new apis, and so on, is not much trouble, but Thinking in Functions is.

All this wouldn’t be so bad if object orientation Just Did It ™. However, just as UML doesn’t quite fit the bill anymore, OO is also not in the perfect place.
For example, how many have been immersed in a service oriented architecture, where types are defined in schema files and then mapped to classes? What behavior do these classes contain? Just about none, instead behavior is placed in auxiliary classes, often using static methods. A part of this is a language problem – Java just makes it hard to add behavior to these types, but that’s not the whole story. And even if it was, then most programmers’ mindset is not geared towards such dynamic behavior-adding – again, Ruby (on Rails) is a good example of this: Most people I know think Ruby is great, but close to everybody also thinks that using techniques as mixins have the potential to make the code very hard to manage. I’m not in a position to say whether this is true or not, but time will probably tell.
I am pretty sure, however, that one of the reasons we tend to make awesome enterprisey systems is that we’re working with some wrong paradigms. I’m in no way a fan of SOA, WS-* and so on, but for some weird reason, many of our customers are, and that more or less forces us to deal with that world. Wouldn’t it be nice if we had some way of dealing with it without jumping through all these oddly shaped hoops?

There are all kinds of suggestions as to how to get this: Tooling, languages, DSLs, and so on. But then again: Is that really the best we can do? (and just to be clear: I’m just writing what I’m thinking in the hope that I some day might either realize that I’ve already got what I want, or am able to clearly specify what it is, I’m looking for).

Want your say?

* Required fields. Your e-mail address will not be published on this site

You can use the following XHTML tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>