I've always tended to blame the popularity of C on the need for a universal assembly language. It's combination of specificity at the machine level, standardization, and extreme portability allow C to function as that de facto universal assembly language, and for that reason I suspect its role there will continue indefinitely.

I should mention that I'm always a bit surprised when OOP is presented in programming courses as a sort of "final model" that is the only possible endpoint for good programming. Like many other aspects of programming, the value of OOP is a compromise between many competing factors, including how human brains organized information, how societal groups support software over the long term, and in the case of object-oriented programming, some pretty deep aspects of how the universe itself works.

And that last point is worth hammering a bit. Read further if you are interested in a physics-level exploration of why certain programming styles exist, how they work together, and where the world may be heading in the future as we expand further on such concepts...

An object in physics is anything that maintains recognizable coherence over time. That in turn allows simple creatures like ourselves to get away with representing the object using only a small number of bits, without endangering our survival too badly. But in terms of physics in the large, the number of things you have to get exactly right to make that kind of simplification easy and common is remarkably large. As humans we don't think about all of that much because quite frankly, we wouldn't be here if it were not true.

Sound too abstract? It really isn't. Imagine for example trying to navigate the road to your friend's house if instead of cars you encountered rapidly oscillating plasma fields and momentary condensations of matter moving with an enormous range of velocities. Such a scenario might cut rather deeply into socialization opportunities, yes? We need objects, we are objects, and the existence of objects provides us with an enormous and critically important level of simplification of the environment around us.

So let's pull all of that back around to software. What do objects in the real world have to say about objects in terms of programming?

Well, for one thing it means that what defines a "good" object in software should really be whether or not the type of data you are handling readily supports the idea of recognizable persistence over time.

With the definition, the easiest forms of OOP are easy to recognized. They are the ones that cop out a bit by using only data that is already "attached" or defined by some real-world, truly physical object like a person, house, or car. Even today, this is still too often the only definition of objects that people get in software courses. That's too bad, because even trivial object-oriented programs need a broader definition than that.

The second and far more interesting category of objects consists of what I'll call immortalized real-world events. By "immortalized" I mean things that at least briefly exist as a well-defined entity or collections out in the real world, but which then disperse and ceases to exist as physically meaningful collections. A symposium is a great example: The symposium exists for a short while as a decently well-defined collection of places and people. But alas, even the best conferences must end, and the individual parts that made them up move on to other activities.

But by using computers and networks, we can make such a transient symposium seem like a long-term object by capturing and maintaining a memory of it as a software object. A great many of the things we do with computers and databases amount to this kind of immortalization of transient events, in which we in effect try to make our real universe richer by capturing and extending it in ways that cannot possibly exist physically. E.g., have you seen a real Pandora lately? Such captures and extensions of real-world pieces help enrich and extend our own lives, economies, and choices in remarkable ways. This to me is the heartland of object oriented programming, the place where it has had, and continues to have, the most remarkable impacts.

A final category of OOP consists of objects that have no close connection to external events, but are instead the infrastructure needed to support our continuing extension of reality using immortalized objects from the real world. This is where you can descend all the way down to the (semi)metal of the computer, creating pieces of persistent reality that like the chemical elements of the real world can be combined quickly and in interesting ways to build new internal worlds. Mobile computing has helped promote the growth of this kind of highly recombinatorial approach, one that again in many ways mimics the recombinatorial features of the physical world. It is also hard: What may seem like a good choice may prove over time to have been an unexpectedly bad one, usually because it ends up blocking diversity and expansion instead of supporting it.

This last category also points the risks of using just one model for programming, since just like the real world, programmed worlds also need processes that don't correspond well to relatively unchanging objects. Earth is full of objects, but the sun is full of highly dynamic energy flows that ultimately are needed to "drive" the objects and activities on lower-energy earth. Similarly, in creating computing worlds there are cases where you must deal with flows and transformations and rapidly changing contexts that, while not very object-like in themselves, are nonetheless absolutely critical to enabling the simpler, more human-friendly objects used at higher levels. It is no coincidence that much of the programming done at the kernel level is not conspicuously object-like, or that it tends to rely heavily on languages like C that are more processing oriented. These are the deeper domains that complement the fascinating diversity we see higher up in computer generated worlds. Trying to force them into pure object models can be a bit like telling the sun it needs to be re-organized as a few billion tidy fireplace objects so that we can understand and navigate more easily from our humans-first perspective.

The other area where OOP can go awry is focusing too much on old object concepts.

Objects in the real world, and especially living objects, have an absolutely astonishing level of ability to interact with their environments in complex and subtle ways. Composable widgets that look each other over, do some compatibility and sanity checks, and maybe even figure out some new ways to interact come a lot close to the real-world biological concept of objects than do the simple frameworks and simple inheritance schemes that we tend to focus on (usually by necessity!) at the code level. This is one of the growth areas for objects in the cyber world, the more "agent like" approaches where reactivity to environment is the norm even within programming itself.

And so much for my "critique" of OOP! Still, though, I hope I've pointed out why creating a richer cyberworld means encompassing diversity of programming styles, rather than assuming that "just one" is all that is needed. My feeling is that the really interesting stuff is yet to come, no matter how mundane much of what we do now is!