Objects Never? Well, Hardly Ever

In the VIEWPOINT section of Communications of The ACM, I found an interesting article entitled "Objects Never? Well, Hardly Ever". It’s a radically different perspective than objects-first or objects-late. He suggests "objects-never" or maybe "objects-graduate school".

The author talked about OOP and made a question about how OOP is used in real world programming environments. He thinks that OOP is not the dominant programming model. For example, he claims, 70% of programmings are done for Embedded Systems where OOP is not really suited.

When some professors in universities wants to talk about the benefits of OOP, they talk about code-reuse. As another example, again, he claims, this is not the real case in real world. code-reuse is harder than what's claimed in universities:

I claim that the use of OOP is not as prevalent as most people believe, that it is not as successful as its proponents claim, and, therefore, that its central place in the CS curriculum is not justified.

It's interesting for me to know how people in stack-overflow think about this? Is OOP the dominant programming model from programmers' point of view?

If I should choose/learn/use just one approach, is it OOP or not? why?

  • 26
    "70% of programmings are done for Embedded Systems"? Is that per project, per developer or per LOC? I have the feeling that 70% of "all prorgammings" is done in Excel. Even non-programmers program spreadsheets. Dec 20, 2010 at 8:41
  • 1
    @Lenny222: If you want my guess, it's 70% of distributed copies of programs are in embedded software, or something like that. Now, some embedded stuff is done in C++, and often a hacked-down version that leaves C and objects, so it seems disingenuous to argue that embedded is never object-oriented. Dec 20, 2010 at 21:01
  • 9
    I think the dominant programming model has long been and will be the big ball of mud. Apr 25, 2011 at 2:45
  • That article makes a bizarre distinction between "classes" and "subsystems" that I don't even remotely understand. It talks about how DiskBrake extends Brake means OOP is no good for a car, because in "the real world" this communication is implemented "by network signals and bus protocols" - what, like DiskBrake implements BrakeInterface?! Maybe it's my own <<43 years' experience, but the examples to me completely fail to back the author's claim.
    – OJFord
    May 30, 2015 at 20:21
  • 2
    The link is now behind a paywall. Anyway, OOP is sort of under-defined and overrated for the most part. But let's just say "most" new programs out there are likely being written in some Java-inspired OOP-esque manner with getters and setters, and classes named SessionManager May 30, 2015 at 23:40

11 Answers 11


In the VIEWPOINT section of Communications of The ACM

If you're interested in practical programming, the proceedings of ACM and the likes is the last source you want to read. These are often [pseudo]-scientific publications with no application in the real world. These are quite often unorthodox opinions made for publicity, for the writer to differentiate himself from the crowd and promote his own person.

I claim that the use of OOP is not as prevalent as most people believe, that it is not as successful as its proponents claim, and, therefore, that its central place in the CS curriculum is not justified.

I tend to disagree with your point. OOP is widely spread and works just fine. By the number OOP-based projects have likely surpassed developments done with other strategies (let's speak about modern time, 15-20 years).

However OOP is not a silver bullet. It works for some developments, doesn't work for others. Just like any other approach.

But one thing I need to mention is that a curriculum should communicate knowledge of different approaches. If it's OOP-based, it's wrong. If it's FP-based, it's wrong. It should cover them all or don't touch this topic altogether.

P.S. Why care about what is dominant and what is not? Just take what is suitable for the project at hand and leave the numbers to "researchers".

  • 3
    They are research papers in fields of Computing that are yet to become mainstream. It takes many years for academia to filter to the real world usually, though it regularly does.
    – Orbling
    Dec 20, 2010 at 8:42
  • 4
    @DeveloperArt: Please note that the paper author has 43 years experience in software development!
    – Ehsan
    Dec 20, 2010 at 8:46
  • 6
    Alan Kay adds a comment, at cacm.acm.org/magazines/2010/9/… - 'By contrast, I have never considered that most systems which call themselves "object-oriented" are even close to my meaning when I originally coined the term.' - which ties in tangentially to my post - "OO? Whose OO?" Dec 20, 2010 at 9:22
  • 9
    @Developer Art: What grates me (a bit) about your post is the "researchers" part. Those darned academics. What did they ever do for us? Oh. Lambda calculus, closures, objects, functional programming, ... But other than that, what have the academics ever done for us? Dec 20, 2010 at 9:23
  • 4
    -1 Computer science researchers need scare quotes? The ACM publishes pseudo-science? Seriously?
    – jprete
    Apr 24, 2011 at 12:49

If OOP is the only paradigm you know, maybe you should learn more. But really, what's OOP actually mean? Does it mean Java or C++? Does it mean Smalltalk? Does it mean settable value slots and closures? (Hi, Scheme!) Does it mean message sending? (Hi, Erlang!)

In short, it seems an uninteresting question to ask. "Is OO useful?" is a better question. And, well, it seems that way. (Certainly it is for me.)

  • 6
    +1 I suspect that in practice OOP has ceased to mean anything other than "a good way of writing code that uses things called objects." Dec 20, 2010 at 13:19
  • The referred article does not think the use of an OO language is a guarantee of oo usage and questions whether there should be paradigms at all since they don't exist in other engineering disciplines.
    – JeffO
    Dec 26, 2010 at 23:30
  • Perhaps the author ought to read William Cook and Matthias Felleisen, who spend a lot of time talking about what is and is not the same in programming. Dec 27, 2010 at 12:27

Where are all the developers doing those "70% of programmings"? out of all the developers I know less than 1% are working on Embedded systems.

So, we have 3 options:

  1. I'm unique and all your friends really do embedded programing
  2. There are armies of developers locked in a basement somewhere doing those 70%
  3. this statistic is made up and the article is bullshit

unless I see some evidence that options 1 or 2 are actually true I'm going with option 3.

(BTW, I do not consider modern mobile development embedded programing, and mobile development is often OO, after all Apple forces you to use *Objective*C to develop for the iPhone)

  • FWIW, I took a few seconds, and came up with half a dozen possible measures for "70% of programmings". The author may well have used a seventh. (Also, embedded programmers are out there, they just tend not to hang out in the same places, and often consider themselves electrical engineers or something like that rather than programmers.) Dec 20, 2010 at 21:08
  • 1
    @David Thornley - lying with statistics is still lying, the author clearly claims that the overwhelming majority of programming in the world today is for embedded systems - and I say this is total bulls#@$t, I'm sure I can invent a measure that shows that most programing in the world is done in the room I'm in right now (that I share with just one other developer) - but any conclusion I build on top of this observation will be as worthless as the made up measure.
    – Nir
    Dec 23, 2010 at 9:00
  • 1
    I'm an embedded guy. I've seen several reports that about 99% of processors produced/shipped are for embedded systems (if it's really necessary I can come back & cite the report(s)). Having said that, I'm sure that nowhere near 70% of all programming is done for embedded systems. I think something like 50% of all processors shipped are 4-bit & 8-bit, but these probably make up 0.1% (or less) of all programming. As David said, there are many ways to come up with "70% of programmings". I wouldn't be surprised if the number was 20-25%.
    – Radian
    Dec 23, 2010 at 14:33
  • +1 for “lying with statistics is still lying”; so true, so true… Apr 24, 2011 at 14:24

I have not facts to follow it up, but OOP isn't the dominant programming model. Just imagine all those in-house apps developed by someone who took a visual basic course, or did some macro programming in Excel.

A lot of applications are just doing imperative programming where all logic is stacked up in a single class or view. This is probably the vast majority of internal simple applications running all over enterprises.

There is nothing wrong with that, there are several ways to solve the same problem. Some better suited than others.

Also as you pointed out, OOP not usefull for all scenarios. There are other models as well.

  • Then again, there might be the question whats required to be described as the dominant model. Is it "amount of apps developed with model X" or is it "the amount of code developed with model X"? Either way I still think that OOP wont be the dominant model.
    – Morten
    Dec 20, 2010 at 8:38
  • 1
    +1 For putting forward the point that, whilst OOP may well be near ubiquitous with trained professionals, the industry worldwide does not quite reflect this and there is plenty of straight imperative code out there.
    – Orbling
    Dec 20, 2010 at 8:44

Whether or not OOP is the dominant programming model is irrelevant, simply put different models fit different cases.

There is no silver bullet.

What Moti Ben Ari is arguing about is an academic assertion, which is already meaningless. However, he states himself that he never found OOP to "make sense", clearly it does to thousands of developers and software engineers and has been used in many many systems...

But, really the point of my answer is this, what good is it to state that one model or another is dominant or not, is that then good rationale for blindly using it? Of course, it isn't.

  • If many people claim to use one model and don't, that's an issue. The question is oop as prevalent as it appears and not about being dominant/better.
    – JeffO
    Dec 26, 2010 at 22:37

This is actually a difficult question to answer reliably. The biggest reason is people like me, who work in custom, in-house applications, where the code never leaves our building. Do we use OO here? I'm not saying. How many other programmers have similar jobs? They're not saying either. We do have job sites, but not all jobs are posted, and not all postings are for real jobs as opposed to recruiters trying to gather lists of names.

Even if I did say we use OO where I work, does that mean the traditional definition from the linked article: Objects, Classes, Inheritance? Or does it mean that I use objects primarily as a means of organizing code? Or does it mean that I really just program to interfaces and hardly use inheritance at all? I'm still not saying, but which of these really counts as OO?

It's not even meaningful to ask if OO is useful until the questions above have been answered, let alone dominant.


Of course it is, because it's the latest buzzword that management has latched on to. It also offers better encapsulation and abstraction that imperative programming, so I think the leap from oop to whatever comes next might take even longer than imperative to oop took.

PS2: If I should choose/learn/use just one approach, is it OOP or not? why?

If you're only going to learn one you should pick a different field.

You should learn about types and encapsulation and all of the other benefits of OOP, and then learn how to accomplish those same things using a functional style of programming.

  • +1 for the comment on picking a different field if you plan to learn one approach. That's insane. Jan 3, 2011 at 20:35

OOP is definitely one of the more dominant programming models in the real world.

Lets face it, even people who design digital hardware, the chip designers themselves, are making a transition to the duo of SystemVerilog and SystemC. These are object oriented programming languages.

Where would OOP not be used? Well if you are coding device drivers its hard to imagine why you'd need generic programming or multiple inheritance OR if you are doing AI functional programming techniques make it a lot easier on the head. There are loads of other situations too, suffice to say though that OOP is a pretty powerful place to be in an oligopolistic programming world.


I'd say no.

I understand there's a huge amount of code out there that is written using an 'object-oriented' language, but generally I find that the code is just procedural wrapped up in classes. (not that this is necessarily a bad thing). The code that I've seen that is written to be more OO in these languages tends to be a horrible mess of dependencies between classes that is typically un-maintainable.

OO is supposed to be about message passing between completely self-contained objects, and we do see that in today's code, but at a much larger-grained level - ie we see these objects implemented as dlls or assemblies or COM objects. 'Components' I've heard them described as.

so, I think that it doesn't really matter if OO is used or not - if the code is maintainable during its life, re-useable to the extent it was designed to be, and quick to develop, then I don't care if it is purely procedural or semi-object-oriented or fully OO. I doubt that anyone can tell you whether the predominant style is any one of these, but I'd hazard a guess that the procedural style is going to be the most common, even if it is chopped up into classes instead of functions.


I think that its important to differenciate a solution obtain by applying an Object Oriented Approach and a solution implemented USING the Object Oriented Paradigm. My opinion about a good object oriente piece of software is to combine both solutions. If you think in objects and you respect the object definitions and interactions, and you problem could be adapted to use this structure, then you'll have a code that is flexible and robust. But if you use objects to solve a code using a procedural paradigm, you'll end up with some nasty mix that wont take advantage from the Objects pros.

I really prefer my code to be Object Oriented, and i've come to realize that at first it could be a bit more annoyng to create a good structure, but when dealing with flexibility and client flash requirements of today, i think it's worth the effort.


I don't pretend to know the exact numbers, or even to make a rough guess, but there are many programming projects that do not involve OOP. I work with industrial robots. The programs tend to be fairly simple and straight forward procedural code. The actual robot operating system is even more so.

Many of our "tools" we use are OOP based, but they run on PCs and not the robot controller. These include editors, simulations, and utilities.

Not the answer you're looking for? Browse other questions tagged or ask your own question.