Is OOP all it’s cracked up to be?: My guest post on ZDNet

Paul Murphy saw fit to give me another guest spot on his blog, called “The tattered history of OOP”, talking about the history of OOP practice, where the idea came from, and how industry has implemented it. If you’ve been reading my blog this will probably be review. I’m just spreading the message a little wider.

Paul has an interesting take on the subject. He thinks OOP is a failure in practice because with the way it’s been implemented it’s just another way to make procedure calls. I agree with him for the most part. He’s informed me that he’s going to put up another post soon that gets further into why he thinks OOP is a failure. I’ll update this post when that’s available.

In short, where I’m coming from is that OOP, in the original vision that was created at Xerox PARC, still has promise. The current implementation that most developers use has architectural problems that the PARC version did not, and it still promotes a mode of thinking that’s compatible with procedural programming.

Update 6/3/08: Paul Murphy’s response to my article is now up, called “Oddball thinking about OOP”. He argues that OOP is a failure because it’s an idea that was incompatible with digital computing to begin with, and is better suited to analog computing. I disagree that this is the reason for its failure, but to each their own.

Update 8/1/09: I realized later I may have misattributed a quote to Albert Einstein. Paul Murphy talked about this in a post sometime after “The tattered history of OOP” was published. I said that insanity is, “Doing the same thing over and over again and expecting a different result.” Murphy said he realized that this was misattributed to Einstein. I did a little research myself and it seems like there’s confusion about it. I’ve found sites of quotations that attribute this saying to Einstein. On Wikipedia though it’s attributed to Rita Mae Brown, a novelist, who wrote this in her 1983 book, Sudden Death. I don’t know. I had always heard it attributed to Einstein, though I agree with the naysayers that no one has produced a citation that would prove he said it.

7 thoughts on “Is OOP all it’s cracked up to be?: My guest post on ZDNet

  1. OOP is one of many methods to manage complexity and (like every new hyped-up technology) it was oversold. I think Java has a lot going for it (everything except for speed really) and Java is an excellent language for beginners who want an environment easy to get started with, easy to use, and hard to hurt yourself.

    Smalltalk (like Ocaml and scheme) is suffering from the problem of being just a little to weird to ever be mainstream. The entry barrier of weird languages kills them by starving them of interest (regardless of how good they really are, once you get past that entry barrier).

    The idea of grouping data together with code that operates on that data makes a lot of sense and exists in a great variety of manifestations. For some specific tasks it makes sense to write a language just to work within that particular task (e.g. SQL). I can remember the initial hype when remote procedure calls (RPC) were going to save the day, then there was SOAP which was RPC with OOP and everything in between. All great ideas, but still waiting to really take off.

    Nowadays, everything is virtual machines and layers of virtualisation with hypervisors and what have you. This too will pass, but that doesn’t make it a bad idea. Machines within machines is a bit of the object model and a bit of the process model (hint: they aren’t all that different).

  2. Well I say don’t believe the hype altogether. I know that Smalltalk, OCaml, and Scheme are considered “weird”, but IMO this is only because of the limited perceptions of most developers. I’ll concede that sometimes these “weird” languages don’t have the tools and facilities that many IT shops now require, and so that’s a barrier to entry. It’s just a shame that these development environments are not used for more greenfield development, like in startups. They are used in some, but there could be more. Think of all the sites that use PHP now instead of Seaside or a Lisp-based web framework.

  3. “IMO this is only because of the limited perceptions of most developers”

    Yes, of course. That doesn’t matter because it still limits the growth and adoption of the language. If developers shy away from a language then project managers have no choice but to also shy away (they are going to need a pool of staff for their project). In any “marketplace” for ideas, incumbency counts for a lot.

    PHP is popular because it is easy to learn, especially for doing a few simple things that what most beginners are trying to do.

  4. @Tel:

    In terms of the marketplace, yes, it doesn’t matter. There’s no use denying what’s dominant. However, this is one of those cases where I have to say the majority is not right simply because it’s the majority.

    For certain low-scale projects, where all that’s needed is a tool for a single purpose, or a small number of purposes, and it will never outgrow those things, then the ready-made solutions are alright. They fit the bill, and they’re effective. The problem is that in reality, if you’re really building something that’s going to grow (and history has shown that most information systems do) the ready-made solutions are terrible. Yet this is what the majority chooses every time, despite its track record. In most cases it’s because the people making the choices don’t know any better. So I’m not going to come down on them like they should. The Quixotic hope I have is that as time passes they will get tired of beating their heads against the same wall over and over again, and try to venture for something that will actually work, and/or demand it of commercial vendors. It may be a vain hope, because by the time most developers get tired of it they change careers rather than venture into unfamiliar territory. The new people who keep feeding into the system don’t know about the past history of failure and so accept the system as it is, and nothing changes.

    For those who are brave enough to venture outside the normal mediocre boundaries there are, for example, commercial Smalltalk vendors who create tools that will fit within fairly traditional development environments, even taking integration issues into account. There are commercial Lisp implementations as well, but I can’t vouch for their qualities.

  5. Pingback: Does computer science have a future? « Tekkie

  6. Software should be built with ease of maintenance as the primary goal. Once software is installed into production it will be in maintenance mode for the rest of it’s life.

    OOP fails miserable with regard to ease of maintenance unless objects are designed with perfection by god.

    Add to that OOP is complicated; right on down to the ridiculous terminoligy used to describe it.
    Instatiation, polymorphism, constructors, destructors, virtual classes, static and instance, containers, collections, on and on.

    OOP is a fad gone mad.

  7. @robert:

    I agree with you that OOP is a fad gone mad, but this is only because of the way it’s been implemented. Some people missed the point of my guest post on ZDNet. I wasn’t saying that OOP as it’s been implemented is the most wonderful thing. I was in fact saying that it’s been bad. The initial idea, though, was good. What I tried to describe was how the designers of Smalltalk implemented OOP, and how it was different than the popular implementations that have been used for the past 15 years. I tried to get across how the original vision was better, but I don’t think I did a good job with that. I mostly focused on how the popular rendition is deficient.

    For example, you don’t have to think in terms of constructors, destructors, or static, or even types in Smalltalk (and some people think that’s a bad thing, and they’re entitled to their opinion). A complaint I’ve heard about the popular OOP implementations is that they try to make everything a noun, even things that should be verbs. This is what makes them so hard to work with.

    I wrote a blog post just recently where I pointed out how easy it is to set up a class in Smalltalk (I was reviewing a Smalltalk implementation called “Pharo”) that creates its own accessors. The only modern OOP language that might make it this easy is Ruby, or perhaps Python. You can do it with the popular OOP languages, but they require one to use a code generation framework that makes things 10 times more complicated. This is because they require you to model a monolithic process out of a collection of objects, rather modeling processes in terms of message passing (with objects as representations of things or ideas, so that relationships can be created), which is what the Smalltalk vision of OOP was all about.

    I think that collections are an improvement over what used to exist in software development. I spent several years writing software in C. There may have been some collection-like libraries available, but a lot of us “rolled our own” collections, using arrays, abstract data types, linked lists, etc. I can tell you that software development, even for applications written in C with modest complexity, was a lot more complicated than it is in an OOP language now. What OOP offers when done well is it makes complex structures more manageable than they otherwise would be in a language like old-style Basic, Pascal, or C. That’s my view, anyway.

    From what I’ve been hearing, computing problems are only going to get more complicated as time goes on, not less. What’s really needed are languages that can get beyond OOP to handle that complexity. I think that what’s also going to be needed is more sophisticated developers who can use languages that embody a more sophisticated architecture, which can handle those problems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s