Perhaps I was a bit too inexact with how I was describing things...
I read the OOPSLA link and I did not mean to say that OO is the absolute best at being able to encapsulate the complexities of programs. I meant that sentence to be a relative measurement, not an absolute measurement, which is why I used the word 'good' instead of something like 'best'. I meant the sentence 'OO is good at being able to encapsulate the complexity of a program' to mean that compared to something like a simple procedural programming paradigm it does a better job at capturing the dynamism that is inherent in many programming projects and the modularity needed to understand the complexities. The functional paradigm may be more ideal at capturing far more of that dynamism and modular requirement than OO... I'd agree with that point and I never intended to say that the OOPSLA article or your conclusions were inherently wrong. I'd say that the OOPSLA article's specific list of points are correct, if you take them in a general sort of way, but that there are many aspects of the argument that are too finely grained as to be almost near-sighted. It's a fascinating read, nonetheless.
I was trying to describe a "usefulness heuristic". I don't take sides on paradigms, languages, etc. (as I said before, I find them silly). The most I'm willing to say is this: there are certain domains of problems that languages, paradigms, and whatevers cover. Use the tool that is appropriate and sufficient for that domain problem. OO may be imperfect at covering all the problems within its domain (and I applaud efforts to make a paradigm more imperfect at that task than OO) but that really is besides the point. There may be times in the future, even if functional programming hit in a big way, that OO might be a more effective and understandable solution than a similar functional solution (I even had a thought experiment to go along with this assertion, but I'm really trying not to be long-winded :) ).
no subject
I read the OOPSLA link and I did not mean to say that OO is the absolute best at being able to encapsulate the complexities of programs. I meant that sentence to be a relative measurement, not an absolute measurement, which is why I used the word 'good' instead of something like 'best'. I meant the sentence 'OO is good at being able to encapsulate the complexity of a program' to mean that compared to something like a simple procedural programming paradigm it does a better job at capturing the dynamism that is inherent in many programming projects and the modularity needed to understand the complexities. The functional paradigm may be more ideal at capturing far more of that dynamism and modular requirement than OO... I'd agree with that point and I never intended to say that the OOPSLA article or your conclusions were inherently wrong. I'd say that the OOPSLA article's specific list of points are correct, if you take them in a general sort of way, but that there are many aspects of the argument that are too finely grained as to be almost near-sighted. It's a fascinating read, nonetheless.
I was trying to describe a "usefulness heuristic". I don't take sides on paradigms, languages, etc. (as I said before, I find them silly). The most I'm willing to say is this: there are certain domains of problems that languages, paradigms, and whatevers cover. Use the tool that is appropriate and sufficient for that domain problem. OO may be imperfect at covering all the problems within its domain (and I applaud efforts to make a paradigm more imperfect at that task than OO) but that really is besides the point. There may be times in the future, even if functional programming hit in a big way, that OO might be a more effective and understandable solution than a similar functional solution (I even had a thought experiment to go along with this assertion, but I'm really trying not to be long-winded :) ).