Replying to blog post discussing Procedural Thinking

published: Tue, 27-Jun-2006   |   updated: Tue, 27-Jun-2006

I was browsing through my website logs this evening and noticed that I'd had a bunch of hits from a blog at http://linamishima.livejournal.com all hitting this article of mine on procedural programming. In it, Michelle, the owner of the blog, was pondering that my article was over-reaching because, in the end, all OOP code gets compiled and executed on a "procedural" execution machine, be it machine code on a real CPU or some kind of interpreter.

This is all very true, but beside the point. My argument is with writing, reading, and maintaining OO programs. I don't particularly care what the compiler does with it all, to some approximation anyway. What I worry about is how people are writing object-oriented code and how it seems to me that they're doing it in a procedural manner but still calling it object-oriented just because it uses classes. It doesn't matter if we're talking about C#, Java, Delphi, C++, Smalltalk or Ruby and whether it's compiled or interpreted or whether there's a garbage collector or not. It's about how we approach the problem to be solved and how we analyze it and design and implement the solution.

Although it is interesting to think about how the compiler translates the code you write to IL, or p-code, or machine code and how the various libraries have been written, ultimately we're going to have to start ignoring it all. I know, I know, I used to be the archetypical tinkerer, writing stuff in inline ASM in Delphi to get that hypothetical few more cycles, but nowadays I really can't be bothered. There are some large problems aching for software solutions and we won't get them if we spend our time thinking about bits and bytes.

Consider Google maps for example. It's bloody amazing the way you can 'grab' hold of the map in your browser for heaven's sake and move the map around. And all that is done in Javascript! I certainly didn't download a nifty compiled-to-the-max C++ ActiveX control to do this magic, it's just script. So I also disagree with Michelle that OO code means less efficiency than procedural code or that IL automatically means slower or that a GC environment is worse than using try..finallys with an obj.Free or two thrown in the finally clause.

I still think that writing object-oriented systems in a procedural manner is bad. And I still see a lot of it. Heck, I write a lot of it myself: my latest article for The Delphi Magazine is on solving Sudoku puzzles using the Dancing Links solution to algorithm X, and I wrote it all in a procedural manner to begin with. It was only when I needed to extend it that I realized that I'd painted myself into a corner and had to refactor it like crazy into a reasonable object model.

Anyway, thanks, Michelle for a thought-provoking post and comment thread. If you need any help with understanding .NET, C#, or Java, or how to change procedural code to OO, send me a note.