[rbarooah]

I'm not so convinced. There was a time when most people had grown up with procedural code. OO offered enough promise that people moved over to it and developed things like Cocoa or Java.

If people aren't moving on, it's not simply because of 'intertia'. It's because the alternatives aren't offering enough benefit yet.

[gruseom]

I think that's nearly entirely untrue. Emotional attachment to what one already knows is the dominant factor - all the more dominant because, in our zeal to appear rational, we deny it.

What will change the paradigm is the desire of a future generation to make its mark by throwing out how the previous generation did things. One can see this trying to happen with FP, though I doubt FP will reach mass appeal.

When you do anything as intensely as writing software demands, your identity gets involved. When identity is involved, emotions are strong. The image of being a rational engineer is mostly a veneer on top of this process.

Edit: 'intertia' - your making fun of an obvious typo rather illustrates the point.

[rbarooah]

You haven't explained how the inertia was overcome before. Nor have you explained what you think would replace OO if not for the inertia.

So this is basically a contentless argument that says people are stuck on OO because they are irrational.

As you me 'making fun' of a typo - I don't know what you're projecting onto me. I simply mistyped the word inertia. I put it in quotes because I don't think it's a cause of anything.

[gruseom]

My apologies! I had typed intertia at one point and thought your quotation marks were quoting that. It seems our fingers work similarly even if our minds do not :)

As for OO, I think our disagreement has probably reached a fixed point.

Edit: nah, I can't resist one more. I believe I explained how the inertia was overcome before: people who were not identified with the dominant theory at the time (structured programming) came up with a new one (object-orientation) and convinced themselves and others that it would solve their problems. Why did they do that? Because the old theory sucked and they wanted to do better. Their error was in identifying with the new theory instead of failing to see that it also sucks. The only reason they could see that the old theory sucked was that it was someone else's theory.

As for "what would replace OO if not for inertia", I know what my replacement is: nothing. I try to just let the problem tell me what to do and change what doesn't work. Turns out you can do that quite easily in an old-fashioned style. But if you mean what paradigm will replace OO (keeping in mind that we ought to give up our addiction to paradigms), who knows? FP is a candidate. One thing we can say for sure is that something new and shiny-looking will come along, until we eventually figure out that the software problem doesn't exist on that level and that all of these paradigms are more or less cults.

Perhaps I should add that I don't claim to know all these things. I'm just extrapolating from experience and observation of others.

[SkyMarshal]

PG covered the inertia problem pretty well with The Blub Paradox [1]. OO is now the blub language somewhere in the language power continuum, and those who don't know any other paradigm equally well are more likely to become and stay invested in it, hence the inertia.

1. http://www.paulgraham.com/avg.html

[gruseom]

I've been as influenced by that essay as anybody here, but I'm not sure I believe in a power continuum anymore. How powerful a language is depends on who is using it. You can't abstract that away, but if you include it the feedback loops make your head explode.

The trouble I have with what you're saying is it suggests that a better paradigm (e.g. FP), higher-level and more powerful, will improve upon and succeed OO. But the greatest breakthroughs in my own programming practice have come from not thinking paradigmatically- to be precise, from seeing what I was assuming and then not assuming it.

Edit: My own experience has been this weird thing of moving back down the power continuum into an old-fashioned imperative style of programming, but still very much in Lisp-land. For me this has been a huge breakthrough. Yet my code isn't FP and it certainly isn't OO, so I guess it must be procedural. How much of this is dependent on the language flexibility that comes with Lisp? vs. just that Lisp happens to be what I like? Hard to say, but I suspect it's not irrelevant. If you can craft the language to fit your problem, you can throw out an awful lot. Like, it's shocking how much you can throw out.