Does OOP help?
From a reader:
...I myself have been in the process of questioning my beliefs with regards to programming. I discovered object-oriented programming in 1997 using first Turbo Pascal For Windows and then Java. When I look back now, I cannot help but wonder if the reason I was attracted to OOP was not so much because it was a better way to program, but simply because it was new. I had never seen it before and relished the challenge of mastering a new skill. Seven years later, however, I have seriously begun to question the entire OOP paradigm.
Does OOP really help us to write better programs? The problem with starting with that question is that it concentrates on the technology. I believe we should start with ourselves. What do we need to know to program well? What does a competent programmer look like? What is the best way(s) to think about programs? It is difficult to recall any discussions which have tackled these questions. Yet it seems that we need to answer them satisfactorily before we can then take the next step and actually decide what programming paradigms help us to program well.
Others have had doubts about OOP every now and then. Here's an opinion that was just published, for example. But all of that author's books are on machine code, so it seems doubtful that he knows OOP well enough to be able to give serious comment on it. People who are in the machine code world tend also to scoff at C.
OOP is an organizational tool, and yes, I've found that it -- especially when combined with design patterns, and a knowledge of OO design (disclaimer: things that I write and teach about, but I wouldn't if I wasn't fascinated with them and didn't believe in them) -- does help tremendously when organizing code and projects. But depending on where you're coming from -- like the machine-code guy -- it may not make sense right away, or be initially harder to use if you come to it with a particular mindset. I also started in electronic engineering, mostly focusing on chips and then adding more and more (assembly) code until the code started getting unruly, and that's what pushed me towards higher-level languages. But with that background, my brain tended to think about what the machine was doing rather than about what problem I was solving (that is, I was dwelling in the Solution Space rather than the Problem Space), and it definitely took time and struggle to get my head around ideas that others (especially those darn Smalltalkers) seemed to bandy about effortlessly. Indeed, it feels to me like only in the last few years, with the aid of languages like Python (and yes, even Java when compared to C++), that push me away from thinking about the low level stuff (rather than simply allowing me to think at a higher level if I put in the effort, as C++ does), have I really begun to be able to think naturally in Objects. And usually, when I start to believe that this is what I'm doing, something fundamental will pop up and slap me, such as this, which will make me realize that there's yet another element that I was either unaware of, or took so much for granted that I wasn't teaching it.
I suppose the best way to put it is that "you can learn the features of a language, but the way you use those features is an endless series of life lessons." Without State, or Strategy, or Factories, etc., polymorphism is indeed a bore. But with knowledge about interesting ways to assemble these features, the world becomes exciting and powerful.
Is OOP the end of the line for programming? Certainly not. It's just a building block on the path, just as procedural programming was. The procedural style of programming was clearly a good thing, and it gave programmers who were formerly chained by the limits of complexity of assembly language great leverage and the ability to accomplish far more with much less effort. But eventually it ran out of "reach," and OOP appeared. The reason these questions come up is not, I think, that OOP has "failed," but rather that we are beginning to see the edges of what OOP is capable of, even as the majority of folks are still coming up the learning curve of what has become thought of as the dominant, accepted paradigm.
Where does OOP fall short? Concurrency, certainly, which promises to become a major issues as multiprocessors become commonplace. Objects just don't seem to conform too well to concurrent programming; the only thing I've seen with any promise is the Active Objects design pattern, which basically serializes method calls to an object which is being driven by a single thread and queue (quite similar to most GUI programming systems such as Swing, but more formalized so that the programmer doesn't have to work as hard, which I think is key). Many have suggested functional languages, which tackle the problem from the other extreme by doing nothing that requires serialization. Personally I don't see the benefits of OOP being discarded in order to solve the concurrency problem; instead, I suspect that a hybrid of ideas will be incorporated into OOP.
I also think that improvements could be made with object packaging systems. One of the great benefits of Objects is the ability to create and reuse libraries, which I do believe may be the greatest leverage we can get out of them. And yet the library packaging and reuse mechanisms are still, to my mind, in a kind of infancy. C and C++ librarians have always been a platform-specific arcana, and Java, while consistent across platforms, involves figuring out Jar files and the never-ending miasma of Classpaths. And as much as I know about Python, the library creation and installation process is still a mystery to me (every time I go to figure it out, it just seems like too much effort, which is a bad sign). This seems to be the place where all the language designers lose interest (perhaps Ruby will have something valuable to offer in this area). But it isn't something that requires a great new paradigm, but rather just some focus on making the packaging issue effortless for both the programmer and the end user (unlike Java, which imposes the nightmare of Classpaths on both the programmer and the customer).
Your questions are appropriate in that they place the puzzle in the realm of ourselves and our psychology rather than assuming that OOP is broken and/or we need some different technology. Indeed, I believe that the benefits of OOP come from the fact that they are closer to the way that we think about problem solving that procedural programming. It's also valuable to notice that parts of every problem involve procedural thinking, and to realize that the initial pitfall was in thinking that (therefore) everything was procedural. What we've discovered, instead, was that procedural thinking is a subset of the bigger picture, just as we are perhaps discovering that OOP is also a subset of a bigger picture, which involves other issues like concurrency. What we may discover is that we collect over our lifetimes a bag of approaches (kind of a Chain of Responsibility pattern), along with ways to know when to apply them. Perhaps our languages may come to resemble this structure, adding things like backward chaining and neural networks to the mix.
Your questions have also sparked another thought for me. I've been reading Harrison Owen's "Open Space Technology" book. I've already had several very successful experiences using Open Spaces, and have been thinking about holding a conference or two this summer based on that technique. But Owen emphasizes that for an Open Space conference to work, you must have an overarching question that establishes the theme of the conference. I realized that the previous Open Spaces I've been involved with have had that question, although it was usually implied and not explicit. Your questions, however, could in fact establish a theme for a conference (in fact, I was involved in something like this in the past, the Writing Better Code summit, but we did not use Open Spaces and I think it would have made all the difference if we had). It's also the kind of conference where everyone has valuable experiences, and sharing those experiences are all that is necessary to impart that value to other participants. And the product of such a conference (a Wiki of notes from the sessions) would be valuable to everyone.
So I propose a 3-day conference called "Building Better Software," which will use Open-Space technology and be held sometime this summer here in Crested Butte. Size will be limited to 70 participants, and cost will be $300.
MindView Home Page