Object Orientation v. The World, Round 1

*ding* Announcer: Begin round 1!

You are an idiot!

I recently read an article attempting to bash the hype out of OO, and kill it for good. Of course, the guy was born in 1750 BC or something, and hasn't even bothered to update his knowledge on recent advancements in programming and data technology in 15 years or so.

Even so, it was a decent read, and had many astoundingly good observations about the differences between OO, and say... relational paradigms. However, these arguments did little to promote his pet paradigm, that of procedural. Granted, his real aim was to bash OO regardless of what that happened to promote. Furthermore, he wasn't able to provide anything that fixed problems with OO but provided all its benefits.

The first interesting observation about procedural programming that has come into my head involves the primitive idea of a class, versus any combination of concepts to achieve something similar in procedural. The idea of a struct comes close to producing what has been perfected in classes for data encapsulation. Programmers very typically grouped their data into structs for transfer and ease-of-use. Similarly, function groups, typically organized in a physical file structure, sought to make functions or subroutines easy to use and manage.

I am convinced that a reasonably intelligent procedural programmer from the '70's, locked in a room for 20 years, would come out with OO as his "revelation" for time spent; of course only to be introduced to the real OO which was invented by ambitious procedural programmers who were sick of having sucky code organization and very little programmatic power.

Unfortunately, you talk to an older programmer who wasn't locked in that box, and had no interest in paying attention to advances in computing for those 20 years, and he will scorn OO because... well... because it's different! He'll use arguments like the Object Relational Impedance Mismatch to claim that OO just plain sucks. You are an idiot!

On that note, here's something to chew on: If the gap between OO and relational paradigms is so vast and irreconcilable, then why are technologies like JPA (Java Persistence API) so incredibly successful. People have for many years doubted the ability of Object Relational Mapping to be of much use in bridging the chasm. However, with an incredibly well written mapping technology, the gap seems to have been successfully bridged. Proponents of old school relational algebra claim that the power of this paradigm has been lost. Interesting... So, when my ORM tool uses joins (probably in SQL) to create a beautiful object graph from my Object Model using its mapping metadata, and I can traverse my object graph in OO without any loss in the power behind Set Theory, that would be... what? A lucky break?

Furthermore, the advances in persistence and ORM technology create a very interesting case for the success of OODBMS's. From the application point of view, and even from a scalability point of view, the data source powering my application is an OODBMS. This, of course, has DBA's hopping mad, because they don't have a job anymore. No longer will the application rely on proprietary features of an RDBMS vendor to provide essential functions like security, concurrency control, and transactions, to name a few. They claim that we waste the power in those vendor products, by implementing them on top of our application technology.

This isn't a case for high-level layer confusion. No, this is a case of proper technology advancement. All the concepts embedded into state-of-the-art RDBMS technologies have paved the way for properly bridging the gap between relational and OO, by moving said features from the DBMS to the application, and leaving the RDBMS to be simply a persistence store, optimized to deal with disk access only when needed for scalability optimization. The first 20 years of DBMS work were on perfecting that very issue. And now that those products also support concurrency, transactions, etc. you're sad to see those functions re-engineered into a more applicable layer of the application. Hmm... touch luck. If you're a dba, I'd say you ought to get more than a business degree, and move on with your less-than-average life.