Today is October 15th, 2007. Very few people celebrate this day, but I think its an important day to remember... because today is the ninth anniversary of the day that Alan Kay, inventor of the computer term "object-oriented programming" (OOP), apologized for inventing the phrase on the Squeak developer's list.
Apparently he was a bit sad to see how the term had become abused:
I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"...
The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.
There's a theory in linguistics (Sapir-Whorf hypothesis) that says your ability to understand something is severely limited by the words you use to describe it... Some Amazon tribes don't have words for numbers, which limits their ability to understand how much they have...
For developers, who spend a lot of time in a 100% abstract world, using words severely limits how you can think about an abstract problem. By definition, abstract problems do not lend themselves well to existing language structures... and if you live and breath abstract problems, naming things significantly restricts how you can think about them. Now, sometimes its a great idea to limit abstract thought with concrete words... such as verbose variable names. Other times, it can be severely misleading or impair one's ability to understand the actual problem... such as verbose variable names.
There are a lot of linguistic traps in programming that affect how you can solve problems... you're dealing with a world that cannot be easily visualized or verbalized. This means that in order to communicate ideas between developers, you're always using bad analogies. These analogies get worse and worse as you try to communicate them to non-programmers. As long as everybody agrees that words like "objects" and "layers" and "logic" are necessary evils, we're OK... but when people start obsessing about the right way to do "pure object-oriented programming", or they start talking about "business logic" as a layer, then we have major problems.
A lot of the Java object-oriented patterns books make people unlearn what they have learned... the right way to use factory objects, interfaces, inheritance, etc., they all seem to be attempts at messaging. Either informing somebody of what they can do (inheritance, strategy), or informing somebody how their behavior can be modified (inversion of control, dependency injection).
The latest pony in this show is probably Google Guice: a slimmed-down version of the somewhat bloated Spring Framework for Java. They claim "pure dependency injection", so much so that you never need factory objects or static methods ever again! Sadly, my sources say the truth is vastly different.
Of course, Python and Ruby fans would mock people for using a language like Java that needs so many patterns in the first place... whereas with scripting languages and data-driven programming, such ideas are nearly intuitive...
Regardless, I'm glad things are moving in the right direction... All this "giving things names" does help when it comes to communicating how software works, plus people seem to be aware of the inherent dangers of verbalizing code... the "patterns for patterns sake" crowd seems smaller than the "objects for objects sake" crowd, which is A Good Thing ©
Anyway, happy Ninth "I'm Sorry I Invented The Term Object-Oriented Programming" Anniversary!
I wonder what the software world will be like on the tenth anniversary?