The problem with OOL is not the OO.
This article is in response to reboler Ratio who posted a few comments related to OOL in my R3 article about Concluding on object creation. And, it's a broad enough topic that it deserves its own article.
Perhaps you know of my history in OOL.... which began in the early 1980's when I was alpha testing Smalltalk at HP, which was from Xerox PARC. (But, it should be noted in fairness, I was also programming on an MIT Lisp Machine during those same days... not in Smalltalk of course.)
For more than ten years, I was a strong believer in OOL. A bit of a fanatic actually.
At Apple ATG, I worked with many from the Xerox Smalltalk team, and we pushed for stronger models of OO within software designs. And, we resisted as much as possible the introduction of C++ , which in fact Larry Tesler jokingly called it C+- (approriate, actually.)
In its purest form, OO is a model of associating behavior with state (function with data). Originally, back in 1982, it seemed like a good idea because real world objects had specific actions related to them. A pen was used to write and draw. A pencil was used to write and draw. We thought, "Wow, there's a pattern, and it seems to be quite natural."
However, it was a false model. A pen does not write and draw, it takes a human to make a pen write and draw. The actions of write and draw do not belong to the pen. OOL is not a complete solution. Too many of the behaviors of objects come from (or are influenced by) sources that are external to their encapsulated definitions.
After ten years, I concluded that OOL was not the answer -- but it was more from the practical reality that everywhere I used OOL it made my code more complex and more difficult to create, maintain, and improve. Whenever I used pure OOL, I lost productivity. (But, if I simply used OO concepts, even without an OOL, such as in the Amiga OS or REBOL kernels, it made the programming model cleaner and easier to understand.)
I realize that in today's programming world, I am a heretic. OOL is ingrained within the fabric of nearly all modern software, justified in terms of cost savings, but rarely withstanding any detailed cost analysis of that claim.
Joe Armstrong (Erlang) once said "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
However, I think that statement is incorrect. The problem is much deeper than that. The problem with OOL begins when you try to encapsulate behaviors, that almost always have external influences, and cracks or divisions begin to occur within the class definition. It breaks apart, and quickly the situation becomes pathological (diseased).
The idea of implicit environment (large or small) is a good one. That's what we call context in REBOL, and it's the cornerstone of the language. That part of OO is fine. (And in fact it's the reason there's an 'O' in the word REBOL. Also, it sounds a lot better than REBCL.) As humans our thoughts and our languages exist within layers of context, a hidden framework, the primary environment of interpretation. Without that context, thinking and communicating would be impractical.
So, that is what we mean when we talk about objects in REBOL. It's about the context of interpretation, and the fact that we really do want that environment wrapped around our expressions. It makes communicating (i.e. programming) so much more efficient.
I don't think you've ever heard me make claims about REBOL being an OOL in the classical sense of the definition, but more of a variation on the idea. It supports many OOP practices, but we don't beat the drum that these are necessarily the best methods to solve problems - really, we prefer language-oriented-programming (of which DSL is an important part.) So, I think at a fundamental level, we agree.
PS: I should also link this old Eric S. Raymond article, Unix and Object-Oriented Languages.