21

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?

OJFord
  • 249
  • 1
  • 8
Ehsan
  • 853
  • 3
  • 8
  • 9
  • 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. – LennyProgrammers Dec 20 '10 at 08: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. – David Thornley Dec 20 '10 at 21:01
  • 9
    I think the dominant programming model has long been and will be the big ball of mud. – whatsisname Apr 25 '11 at 02: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 '15 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 – Charles Salvia May 30 '15 at 23:40

11 Answers11

20

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 '10 at 08:42
  • 4
    @DeveloperArt: Please note that the paper author has 43 years experience in software development! – Ehsan Dec 20 '10 at 08:46
  • 6
    Alan Kay adds a comment, at http://cacm.acm.org/magazines/2010/9/98017-objects-never-well-hardly-ever/comments - '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?" – Frank Shearar Dec 20 '10 at 09: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? – Frank Shearar Dec 20 '10 at 09:23
  • And what of all non-schooled developers? Whom learn of OOP only After having implemented several solutions imperativly? – Morten Dec 20 '10 at 09:31
  • 1
    @Ehsan: 43 years in software development, or 43 years in academia? These can be the same thing, but often aren't. A tremendous amount of good stuff comes out of academia, but that doesn't mean everything in academia is good. – David Thornley Dec 20 '10 at 21:05
  • 4
    -1 Computer science researchers need scare quotes? The ACM publishes pseudo-science? Seriously? – jprete Apr 24 '11 at 12:49
  • 1
    @Morten: Most non-schooled developers are rubbish. There are exceptions, but they're just that: _exceptions_. The big difference is that developers who have taken proper schooling tend to be aware of the importance of getting the data structures and algorithms right, and that really matters. (But don't get me wrong; there are many poor developers who took degrees; they typically didn't pay enough attention to DS&A…) – Donal Fellows Apr 24 '11 at 14:22
  • "I tend to disagree with your point" - note that the quote in your answer is actually a quote from the article; not OP's own words. I have edited the OP accordingly. – OJFord May 30 '15 at 20:11
17

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.)

Frank Shearar
  • 16,643
  • 7
  • 48
  • 84
  • 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." – Larry Coleman Dec 20 '10 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 '10 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. – Frank Shearar Dec 27 '10 at 12:27
9

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)

Nir
  • 331
  • 1
  • 3
  • 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.) – David Thornley Dec 20 '10 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 '10 at 09: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 '10 at 14:33
  • +1 for “lying with statistics is still lying”; so true, so true… – Donal Fellows Apr 24 '11 at 14:24
8

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.

Morten
  • 556
  • 2
  • 10
  • 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 '10 at 08: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 '10 at 08:44
5

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.

ocodo
  • 2,948
  • 3
  • 23
  • 31
  • 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 '10 at 22:37
4

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.

Larry Coleman
  • 6,101
  • 2
  • 25
  • 34
2

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.

Josh
  • 113
  • 1
1

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.

Fanatic23
  • 7,533
  • 4
  • 31
  • 56
1

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
0

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.

guiman
  • 2,088
  • 13
  • 17
0

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.

Jim C
  • 883
  • 4
  • 12