Home > Programming > Object-Oriented Programming: I just don’t get it!

Object-Oriented Programming: I just don’t get it!

I thought of entitling this post “Object-oriented programming is the pesto of programming paradigms,” to paraphrase the philosopher Costanza. Since I was in middle school, I’ve been hearing people say “object-oriented” with a strange air in their voices as though they were discussing Camus or Beckett; they also often have the annoying habit of throwing in “modern” when talking about their favorite languages.

When I really started programming a few years ago, it came up right away when I was looking for reading material. I studied quite a bit of Python, but since Python is a multi-paradigm language (in a way), I wasn’t forced to learn how to program in an object-oriented style. This past week I decided that since I’m doing real work in Python, I should give real object-oriented programming a try to see what it’s benefits are. Here I report my conclusions.

1 My Programming Background

A couple things you should understand about me and my programming projects are that (a) I’m a Unix guy and (b) my “programs” are typically along the lines of “input some values and spit out some different values.” I’m not building large programs with complex user interfaces; I have made somewhat complex interfaces in the form of command-line arguments are runtime configuration, but they are still batch-oriented, non-interactive programs. I get the impression that nowadays these are no longer typical. Although my impression is that most programming books only include batch-oriented programs as examples, most people I encounter on the web, and most programming reference guides seem oriented towards either web programming (where the user interface is a browser), or GUI programs.

As for (a) I don’t like limits and labels, but nine-hundred and ninety-nine times out of a thousand, the solution I end up using follows Unix philosophy and GNU standards. I don’t think this is a concerted effort on my part, but pretty often when I think I need to use a language like Python, I end up writing a shell script or make target that gets the job done, often in less than twenty minutes.

2 What is Object-oriented Programming?

No one has given me a satisfactory answer. Alan Kay should know. I certainly don’t know. You will not get a good definition from someone who goes around saying “object” and “object-oriented” with his nose in the air. Nor will you get a good definition from someone who has done nothing but object-oriented programming. No one who understands both procedural and object-oriented programming has ever given me a consistent idea of what an object-oriented program actually does. If you’re reading this, please comment!

The usual definition goes something like this:

OO Zealot: objects have attributes and methods.

Me: Wait, I asked what object-oriented programming is, not what objects are; I know what objects are, every programming language has pieces of data that procedures operate on

OO Zealot: Yeah, but in an object-oriented language, you can define your own data types

Me: I define new data types in C all the time, they’re called structures

OO Zealot: Yeah, but in Java these data types have attributes that they carry with them, that are like procedures, but they’re called methods

Me: Okay, so you can pass functions as arguments? I’ve been doing that in Lisp and Scheme for a long time; it’s kindof old news

OO Zealot: Yeah, but in C you can’t tie a function to a piece of data like you can with object-oriented programming

Me: Sure you can; you can define a structure with a pointer to a function, whose other fields are the arguments of that function. Then you can create a function that takes the structure as an argument and evaluates the function pointed to. In Scheme you can also create what’s called a closure where you basically return a procedure that encapsulates the environment at the time the definition is called. You can use these closures to evaluate the same argument in many different encapsulated environments; you can make whole lists of closures fairly easily. In Scheme you can also travel backward in program execution by capturing the continuation of an evaluation, kinda like a throw-catch.

OO Zealot: Oh.

I don’t mean to alienate people who really know what object-oriented programming is, but that is based on real conversations I’ve had. The people who advocate object-oriented programming at me have seemed at times to just be really narrow-minded and totally ignorant ofother kinds of programming. They think object-oriented programming is the only way, and seem like they’d have trouble learning any other kind of programming. That does not mean I think that anybody who advocates object-oriented programming is a bad programmer, but the people who have advocated it to me have sounded less knowledgeable about programming to me than they thought they did. Is the reason lots of languages phrase their documentation in terms of object-oriented programming because there are a bunch of people out there who can’t do anything else?

Furthermore, none of the definitions of object-oriented programming given by these devotees, or that I have found go beyond defining what “object” means in the phrase “object-oriented.” Some of them also say that “objects pass messages to each other” or “the program is a set of interacting objects,” but that doesn’t really say what goes into the program text of an object-oriented program.

I had a little Eureka! moment when I realized that sure, you could define a program, with “endowed objects” just by instantiating a certain set of such objects, and maybe calling one or two methods. I headed over to my favorite programming showcase, 99 Bottles of Beer, to get some examples of object-oriented programs in languages that are the biggest sellers of the object-oriented lifestyle. Sure enough, what I found was exactly what I refer to above, however it looked an awful lot like a plain old imperative program. What I see in both the C++ and Python versions said to “object-oriented” is that the programmer defines a data type and within that data type he defines some procedures (called “methods”) and then he calls those methods on an instance of that data type. Read that again: defines a variable and calls procedures with that variable. That is no bloody different from imperative programming.

So on a cycling trip across Durham I closed the intellectual book on object-oriented programming again, thinking that I personally have no need for it. Maybe it comes in handy for really huge, really complex programs, but as I said, I try to avoid that at all costs, and I’m not designing a new web browser for anybody. Maybe it has some applications, like in video games, where these “objects” will interact in unpredictable ways, but that’s not what I’m doing either.

And maybe it makes somebody a lot of money, but I’m in it to learn, not to make money.

3 I gave it a try

I still had this challenge of using object-oriented programming languages, especially their libraries. Pythonis an excellent multi-paradigm language, but its libraries work within the object-oriented paradigm. This makes perfect sense because one of the advantages of object-oriented programming is that the datatypes from the library come with their procedures pre-defined. That’s cool. You still have to look up what those procedures are and what they do, and every library that comes with custom data types comes with functions that take advantage of them. Therefore this isn’t unique to object-oriented programming either: think about how useless a library would be if it didn’t work this way. I would like to build some more complex programs in Python, and use its web, XML-processing, and database libraries, so I really should learn how to use some object-oriented programming techniques.

What I had already was a functional program, in Python, which executed a population genetic simulation. For iterating equations, functional programming makes the most sense, and so far Python is the best functional (multiparadigm) language that works in a Unix-like environment. Basically I had a function that did the iteration, that took a function and its argument as arguments. Nice, clean and simple.

What I tried to do in Python was to define a class that did the iteration, and a derived class that defined a specific function to do the iteration. Here’s what I ended up with:

#============begin satire============
self.self.self.self.self.self.self.self.self.self.bungle ()
#=============end satire============

I’m not an experienced Python programmer, but I felt like this wasn’t really capturing the essence of the problem like OO advocates said it would. Well, a program can only be as good as the programmer. But here’s a more critical question: can you take a mediocre programmer, and give her a C++ or Java project and say “Here, use object-oriented programming” and have the program come out better?

4 Ask the experts

After that half-hearted (is that the right body part?) attempt at object-oriented programming, I thought I should see what some of my favorite hackers had to say.

Paul Graham said this:

Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations.

Immediately I thought “Oh yeah, that’s true, I’ve never had that problem.” In other words, I’ve done a lot of programming in Lisp, Scheme and using Python in a functional style. You can even program C in a somewhat functional style, as long as you keep track of the scope of allocated versus stack objects. In C you have to remember to think about things the way the computer does, whereas in Lisp you have a huge pile of abstractions already there. However, it’s pretty easy to build up abstractions in C without moving to C++ or Objective-C.

Graham writes more:

Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers.

So this answers my question from above. Giving a mediocre programmer a confining paradigm to work within will not produce better code, but it may produce a better-behaved programmer. In my case, it won’t do me any good whether I’m good or mediocre. Graham’s point is supported by evidence collected by Eric Raymond:

… inspection of open-source archives (in which choice of language reflects developers’ judgments rather than corporate mandates) reveals that C++ usage is still heavily concentrated in GUIs, multimedia toolkits and games (the major success areas for OO design), and little used elsewhere.

Richard Stallman had this to say:

Emacs Lisp is powerful enough. Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program.

Emacs does, by the way, have an object-oriented programming framework called eieio.

5 Conclusion

As it stands, I cannot justify learning an object-oriented programming style. I may want to learn C++, since it seems to have a lot of interesting standard library datatypes that might be useful in my research. However, anyone I’ve asked whether I should learn C++ has said “Don’t bother,” for one reason or another.

I would really like to know what you all think: it’s been at least four years that I’ve been trying to understand the value of object-oriented programming when functional programming and imperative programming seem so simple and obviously useful to me. A critical piece of my own story is that I have made all my decisions about what to learn on my own: no one told me to learn C++ for a job. I decided to learn Scheme, C, Python, Perl and many other languages because I did research and found out they were right for one reason or another. The one programming language I learned for my job was Stata, which is a special purpose language (incidentally it does have a class system). On the other hand, most of the people advocating object-oriented programming at me have been either given the task of using an object-oriented language (e.g. Java), or learned it as the pinnacle of a programming class. I’ve never taken a programming class.

  1. concreteAbstraction
    July 9, 2010 at 02:44

    Hi there,

    Head First OOP is a great book to learn to code (and think) in Object Oriented Paradigm. Slowly, you’ll be able to apply these principles into the Object Oriented language of your choice. When you’ll think in terms of objects, it will be a whole new world.

    Each programming paradigm has its own weakness and strengths. IMHO, the strength of OOP lies in inheritance, encapsulation and polymorphism. Sure you can create stuff that keeps state in C using structs but im not sure you could have another struct that has exactly the same behaviour as your existing struct but has one additional capability, you’d end up duplicating code of the existing struct to the new struct you’ll be creating. In OOP, you create objects and just let them interact with each other — it’s so beautiful as compared for programming something with the same effect using procedural paradigm.

    The strength of OOP is also the source of its weakness, i.e. keeping of state leads to programming with side-effects, you can only deal with objects (no passing of function around) and most of its features are prone to abuse (i.e. some programmers apply inheritance to everything causing classes to fan out sporadically!).

    IMHO, functional programming however is an exceptionally beautiful thing. It is Turing-complete! In fact, you could even do OOP using purely functional programming (i.e. keeping of state becomes a consequence). Learning curve for functional programming languages however are quite steep as compared to learning OOP.

    Still it all boils down to using the right tool for the right job.
    Just my 2 cents.


    • July 9, 2010 at 08:35

      I agree with everything you say, and that’s why I wanted to give it a try. Your viewpoint is exactly what I was looking for in a reader, i.e. someone who can see that OOP is not a panacea. I don’t necessarily agree with people who think object-oriented programming as a concept is stupid, but it’s not a silver bullet that is guaranteed to work better in all circumstances. There are some people who think the same thing about functional programming: I certainly did. But after trying to do some numerical simulations in Lisp, I realized that C, Fortran and C++ were the most widely used for really good reasons (only some of them related to programming style), and I decided on C. Functional programming is fantastic, but I’m not going around talking about it like it’s magic all the time, like some OO-fanatics I’ve met do with object-oriented programming.

      Again, I’m saying that object-oriented programming as a concept may be failed by its fanatics who don’t get that it’s not a programming panacea. I have met people who talk about object-oriented programming as though it’s the pinnacle of programming skill, and yet they can’t show me that they have good knowledge of general programming principles. And these are people who have taken programming classes.


    • July 9, 2010 at 08:46

      I should add, my point about C structs carrying function pointers was that this misunderstanding occurred in a real conversation with somebody who had been misinformed in a university-level programming class about what could and could not be done in C versus Java. She just didn’t know.


  2. July 14, 2010 at 23:57


    An Object is a Thing that you can Interact with in defined ways.
    Object-oriented programming is programming based around objects.
    Object-oriented languages are programming languages based around object.

    The first (objects) can be created in C.
    The second (OOP) can be done in C. For example, fprintf(,,) is object-oriented, with the FILE* being the object.
    C is not, however, an object-oriented language, because it doesn’t provide a syntax for interacting with objects. And ONLY because it doesn’t provide a syntax for interacting with objects. Encapsulation, polymorphism, inheritance, etc., are nice, but what ultimately defines OO is the objects themselves, not how you create them.

    The secret, put simply, is to figure out what should, and what should not, be an object. File-system directories, GUI (or, if you want more than one, text-prompt) windows, etc., are pretty good choices for objects.

    Personally, I suggest learning C++, but not TOO much. Learn C++ classes, and templates, but move on to something else within a few weeks, and don’t get too used to RAII (Java, for example, doesn’t have it). At some point, learn prototypes too.


    • July 15, 2010 at 11:00

      I’m not sure I understand your fprintf () example. I think your suggestion for C++ is good, and as I said there are other advantages to C++ other than OOP concepts. The question is, should I take the time to learn C++ when I have already been using Python, Lisp and other languages for years and can use them very effectively? The other thing about C++ is how influential it has been. I have always been confused by the amount of discussion in the Scheme community about namespaces, modules and so on; I didn’t know for a few years of Scheme programming that these concepts came into wide use from C++ programmers. In other words, I’m pretty sure people had moved from C++ to Scheme and were demanding some familiar concepts.


  3. July 20, 2010 at 07:13

    You should learn C++ enough that you understand the basic concepts:
    What is a class, what is an instance, how are they different from a prototype (which C++ doesn’t have, but Javascript does).
    What is a namespace, how is it different from a class.
    Why are templates equal parts joy and frustration.
    Learning this much (or little, as the case may be) shouldn’t take too much time.

    And since you know Scheme, one more: How can a hashtable (sorry if I got the name wrong, I’m not a Lisper) be used to implement an object?

    As for modules, those aren’t actually from C++. I think they were made famous by either Java (which is mostly a sub-set of C++) or Python.

    Sorry about the fprintf example, you said that you knew C so I ran with it. fprintf is object oriented because it works on a target, with that target being an opened file. In essence, fprintf is a ‘verb’ that’s associated FILE pointers, which are ‘nouns’. That is the fundamental principle of Object-oriented programming: Interacting with a target, through some mechanism, without necessarily knowing what (or sometimes even where) the target is. An object could be anything from an integer, to a supercomputer on the other side of the planet.


    • July 20, 2010 at 09:24

      And since you know Scheme, one more: How can a hashtable (sorry if I got the name wrong, I’m not a Lisper) be used to implement an object?

      I’m not sure if this is a pedagogical question or if you’re really curious, but my answer is that closures can be used to implement a simple object system. I don’t know how hashtables would be used, I don’t know much about hashtables. A closure is simply a returned lambda-body that contains local (lexical) functions. When you evaluate the definition, it returns a lambda body (a function, basically) that takes a message as an argument. You can pass a “message” as an argument to the evaluated lambda-body. Scheme was developed (so Dick Gregory tells it) in an effort by Sussman and Steele to understand object-oriented programming. They happened upon a way to write (almost) pure functional language in Lisp by defining a small functional core.

      The big problem with Scheme is that most implementations don’t have such great libraries — though there are exceptions. When I use Scheme, I use Guile, although I’d like to try Arc, which is meant to address the former problem (i.e. the purity of Scheme and the libraries of Common Lisp).

      My point about modules still stands: people learned them somewhere else (other than Scheme) that I was unfamiliar with, and seemed uncomfortable when the core of Scheme did not provide a reified mechanism. That’s how R6RS was born.


    • September 11, 2010 at 04:13

      I’m not sure what you mean by a prototype with Java; perhaps it’s different than a prototype in C/C++.

      C/C++ have a feature called prototypes or forward declarations which might look a little something like this:

      int somefunc(int a, int b);

      Declared anywhere a function can be defined, it tells the compiler to expect a call to somefunc, providing the information that the compiler needs to know at that time (what it takes, what it returns), without providing a definition. It is expected a definition will be provided before compilation ends.

      Is a prototype in Java something different?


  4. September 11, 2010 at 04:54

    I would say to you, sir, that you understand Object-Oriented design just fine. You are looking for a deeper explanation when in fact, there is not one.

    In fact, I had just this discussion earlier here, but the original author mistook my disagreement with the hype of “object-oriented programming implemented in C++, versus what is essentially object-oriented programming in C,” with a lack of understanding of object-oriented programming, or how C++ features work.

    But let’s beat a dead horse for a while anyway. Take a game, think of it as an object. What do games have? They have rulebooks, players, maybe plies(a single player’s decision) or turns, etc. You might have methods that read a rulebook (usually just one, but a replaceable one in good games (the logic scripting)), add a player, begin the game, end the game etc. Each of these things, the rulebooks, players, plies/turns, would be objects that are members of the game object, each with their own member data/functionality. Players might have names, teams, scores, etc. and come with member-functions to fiddle with all of those.

    The object oriented mind-set comes when you think of EVERYTHING as an object, because some day if you implemented your game correctly and object-orientedly enough might run inside something like the “game pig” in System Shock 2.

    Personally, I think object-oriented programming (the way the OO snobs think of it) is probably best for event-driven GUI programs and large projects that have problems that lend themselves to being thought of as objects. Outside those, you simply should approach each problem in the way it lends itself, and even feel free to mix your paradigms in your programs. C++ caters to this.

    You should learn C++ for at least four good reasons:

    Because you have a good head start already, being a C programmer.
    Because C++ is used as the language of choice for professional developers working on commercial applications.
    Because C++ is an outstanding, powerful, and expressive language capable of generating highly complex applications without sacrificing speed and efficiency.
    Because C++ has a good object model, and you should practice object-oriented programming.

    You should practice object-oriented programming for at least two good reasons:
    It will get you ready for when you DO have a need for a large project, or one that lends itself to the object-oriented model…
    … and why the hell not?


    • September 11, 2010 at 20:27

      Thanks for reading: I’m glad to get more discussion on this topic.
      As to reasons I should learn C++:

      Because C++ is used as the language of choice for professional developers working on commercial applications.

      Hopefully my life will never come to such a tragic state! To paraphrase a musician I once spoke to “I don’t hang out with professional programmers, I’m a scientist.” What the guy actually said was “I don’t play bluegrass, I’m a professional musician.” Anyway: I’m not lumping you in with these other uninformed people, but quite a few people have said to me “C++ is more practical [i.e. you can get a job doing it] than C.” I’m a scientist, and officially not a programmer. What I actually do is programming, but I won’t be applying for jobs saying “I’m a really good programmer.” I don’t think I’d want that job. Maybe, we’ll see what happens.

      I have been thinking of learning C++ again recently, since it seems to be such a well-supplied language, in terms of libraries and new syntax, outside of the whole object-oriented arena. So definitely all your other reasons do apply. Again we’ll see what happens. I’m thinking of focusing most of my future projects in Guile.


  5. Phen
    September 17, 2010 at 03:50

    I think the problem is that while a lot of people “do OO”, not many have taken the time to think about why and what it buys them. I’ve struggled with it a lot, because despite what all the literature (or should I say marketing material?) says, OO does not model my natural thinking. All that Computer.firePhasers() nonsense makes me feel like I’m in a cheesy Star Trek pantomime.

    Anyway, the widely accepted (though often disputed) tenets of OO are:

    1) Inheritance
    2) Encapsulation
    3) Polymorphism

    Inheritance breaks down into code inheritance, where the base class provides code that all the children can use without modification, and interface inheritance, where all the children are guaranteed to provide the same functionality as their parents. The later is more interesting, as it provides the basis for polymorphism (or programming to the interface).

    In a procedural, statically typed language like C, you can imagine having a lot of functions with names like foo_float(), foo_int(), foo_char(), where you want to foo the x. Because of this “polymorphism”, you as the library consumer can just foo(). You don’t even have to know or care if that x is an int or a float, because the compiler or runtime (depending on when binding takes place) will sort it out for you. I prefer to think of it as dynamic dispatch, rather than polymorphism. Indeed it is possible in other programming paradigms too. An excellent example is the Common Lisp Object System (CLOS), which can do multiple dispatch rather than the single dispatch that usually comes with OO languages.

    Encapsulation is my personal bugbear, because you so often have to break (or at least seriously bend) it. You can think of it as namespaces on crack if it helps ;). Each object’s data is private to itself, so you define the ways that it can be interacted with at the interface level. Unfortunately there is a problem. Should an object know about printing in addition to its core domain knowledge? How about persisting to a database? Or network communications? If you answered “yes”, you’re in the minority. If you answered “no”, congratulations, you now have to expose the guts of your objects to all the world, so other objects can get the data they need to display/persist/transfer. Sure, it’s still a bit better than global variables in that you’re unlikely to accidentally use the same name in the global namespace, but that ability to restrict the kinds of things others can do to your object’s state is all but lost. Your fancy objects just became c structs (more or less).

    Ranting aside, the great thing about multi paradigm languages, such as C++ and Python, is that you can benefit from all these paradigms without any effort on your part. It’s in the libraries, stupid! 😉 OO lends itself to the creation of easy to use libraries and event driven programs (such as GUIs). If you need to do either, it’s worth considering, otherwise write your procedural or functional code in a multi paradigm language, so you can use their libraries and forget about the added complexity.

    I’d say you should learn C++ even if you’re never going to use it. It has a lot of really interesting features over plain C, like templates and template meta programming (compare LISP), RAII (no other language I know has this idiom, and I sorely miss it in every single one), operator overloading, friend classes and functions and multiple inheritance.


  6. January 26, 2011 at 21:58

    Here‘s a nice explanation of object-oriented programming. It sounds like the concepts are simple, but it sounds like it makes programming incredibly complex. My main question after reading this short intro is Why? If your program requires that level of complexity, perhaps you shold reconsider how you’re writing your program.


    • January 28, 2011 at 15:09

      Thanks for the compliment and the link!

      The concepts are simple, but can appear complex. The way they’re presented in academia and drive-by tutorials does little to address this (that’s why I’m writing a book).

      But, once you’ve internalized the concepts (a little time and experience does the trick; that’s why they call it a ‘paradigm shift’) they do make programming (of _some_ things; always use the right tool for the job!) easier and less complex.

      In my case, I re-invented (or re-discovered, if you prefer) object-oriented programming out of necessity, in Assembly language (long ago on a Commodore 64 far away). The clever techniques I came up with to enable sane code reuse in a 2D CAD application had a pattern; the pattern was OOP (as I found out later).

      As an experienced input-transform-output programmer (your description ;-)), you understand the value of classifying data once upon input. OOP – in some respects – extends this up-front classification to the code that transforms the data. Take one of your old programs and look for switch statements; chances are that the conditions in the switch statements combined with the classification conditions (used to sort out the input data) implicitly defines a class.

      Best regards,
      Steven A. Lowe
      Author, “Object Mechanics: A Practical Guide to Object-Oriented Programming”


      • January 29, 2011 at 15:08

        I definitely see your point: I’ve found myself doing things that are a lot like object-oriented programming in Scheme and in C. Just thinking about data types I come up with seemingly object-oriented ideas. I think the difference is whether I’m going to beat people over the head saying “object-oriented.” Prof. Jerry Cain has said that many C++ programmers are really programming in C without knowing it, i.e. doing imperative programming and compiling it with a C++ compiler. I suppose it’s possible to go the other way: to use object-oriented programming without realizing it.


  7. January 27, 2011 at 00:54

    Some things are just that complex. Here’s Jobs on the matter:

    That simplicity is the ultimate sophistication. What we meant by that was when you start looking at a problem and it seems really simple with all these simple solutions, you don’t really understand the complexity of the problem. And your solutions are way too oversimplified, and they don’t work. Then you get into the problem, and you see it’s really complicated. And you come up with all these convoluted solutions. That’s sort of the middle, and that’s where most people stop, and the solutions tend to work for a while. But the really great person will keep on going and find, sort of, the key, underlying principle of the problem. And come up with a beautiful elegant solution that works.

    In cases like these, where the sophistication of the project warrants it, OO design shines.

    Plus, for projects that are big enough to have more than one manager and/or team it’s a must. You have to be able to create documented classes that contain public methods for their principle function or setting/accessing data, as well as private data associated with getting this done. It would also have private methods for internal use, and possibly also a few public data for reference, or even some convenience constants. This part of it (data encapsulation) is a boon for large project programmers.


    • January 27, 2011 at 12:58

      Thanks for reading. I see your points, but I don’t think they apply to me.

      In cases like these, where the sophistication of the project warrants it, OO design shines.

      You may have found that in your programming career. I have usually found that the problems I’m encountering in research are usually unnecessarily complicated right away by people hastily applying the wrong ideas. I’m a mathematician, I believe in studying the problem. For my own taste in computing, however, I often find that I’ve overestimated the complexity of the problem by failing to see that it’s a version of some already-solved problem. I prefer building complexity, or solving seemingly complex problems, by gluing together simple solutions for small steps of the problem. I’ve been using computers this way (i.e. using Unix) since I was thirteen, and it works for me.

      Plus, for projects that are big enough to have more than one manager and/or team it’s a must.

      This is the gist of the quotation from Paul Graham. I’m never going to be in that situation: I meant the same thing when I said I’m not going to learn C++ or Java because someone tells me I will get a better job knowing it. I don’t want those jobs, I’m a scientist. If the biggest advantage of object-oriented programming is for large, subdivided teams, then people should stop telling me to use it because I’m not in that situation.


  8. gigi
    January 29, 2011 at 12:04

    C++ is not C with classes. There are actually two C++ languages – the old C++ (C with classes), and the new C++ (so called “modern C++”).


    You only talk about the old style C++ in your article.

    OOP starts shining on large projects (20+ KLOC). I have written some large personal applications – a simple audio editor, a simple 3D engine, a infrastructure for financial data analysis and automated trading. These would have been much harder to write and maintain without OOP.

    BTW, my language of choice is Python. I only use C++/C# for the performance critical parts.



    • January 29, 2011 at 15:04

      You only talk about the old style C++ in your article.

      When? How would “new C++” be different?


  9. Mark
    June 19, 2011 at 22:05

    The main point of OO is that the functions that operate on the data are actually bundled along with the data. This has subtle but important implications.

    Consider that you write some sort of stack data structure that supports the obvious operations: top, pop, push. You can do this with functional programming, where (pop stack) gives you back the popped stack, for example.

    Now, imagine that you want to experiment with two different stack implementations. So as a functional programmer, I’m going to put the different implementations in two different files/modules. Now, let’s go further and imagine that you want to write some code that uses both of these stack implementations. You have to be super-careful to make sure that you call the right functions from the right modules on the right stack objects. Let’s say Stack1 is the name of the file with one implementation, and Stack2 is the name of the file with the other implementation Your code might look like:
    (Stack1.top s1) + (Stack2.top s2)

    It’s starting to get messy, isn’t it? Now imagine you want to do some sort of processing over some sort of collection of stacks, each of which might use some different underlying implementation. How are you going to do that? Are you going to somehow determine which type of stack it is, and call the right function from the right module to process it? Good luck with that.

    In OO, you can just do s1.top() and the “right version” of top for that particular implementation will automatically get called.

    So OO definitely gives you something unique that functional programming doesn’t. It has nothing to do with static typing and nothing to do with big/small teams.

    That said, I think that OO is rarely useful.


    • June 20, 2011 at 10:43

      I disagree that OO has a characteristic that functional programming does not. I would just put the two different stack implementations into two closures.


  10. December 14, 2012 at 10:31

    Programming is loops and conditions. Everything else is just a way of organising things.

    The ‘everything else’ is prone to the politics and fashion. When I started progrmming databases tended to be hierachical affairs with data-dictionaries. Then it all went set-theory with SQL and I had to get my head around a different way of organising stuff. Then the DOM came out and they went heirarchical again, probably the worst match for set based databases! Sometimes I wonder if it’s all just a job creation scheme for university professors!

    OOP has some laudable advantages for large projects in large businesses that have people whose only job is to plan or to procure, but for the rest of us in small businesses, quick and dirty programming saves a ton of money.


    • December 17, 2012 at 10:26

      Sometimes I wonder if it’s all just a job creation scheme for university professors!

      Everybody has to have their own scheme: for politicians, it’s mandating things like Electronic Medical Records. For professors, sadly it is just about making things more complicated. However, perhaps it’s not the professors that are at fault: perhaps they are just having fun and learning, and other people are cashing in.

      Thanks for reading.


  11. wirrbel
    September 2, 2013 at 12:56

    Object oriented programming has been overloaded and misunderstood. It is definitely a clever technique when applied to the right problems.

    Now it is not completely clear what object orientation means, which is part of the problem. I would say that the smallest common denominator of OOP-definitions is: Polymorphism.

    Polymorphism means that an invocation of a method depends on the type of the object(s) it acts on. I.e. You might have a method draw() to draw something. Now instead of defining draw_duck() and draw_swan(), kindofabird.draw() will invoke the specific draw function for the kindofabird object. This is really handy in a lot of places such as GUI programming. Also it does make a lot of things easier if done right.

    For example I have been writing some Scheme code lately, and I seriously get annoyed at lack of polymorphism. You have different procedures such as `list-length`, `string-length`, `vector-length`, etc. Concatenating two lists and two strings — use different procedures. With polymorphism, just a `length` procedure would be enough.

    Now if you confuse the polymorphism pattern with “top-down programming using classes”, then you can end up in a cargo cult where you just stash imperative code into classes — which does not have an enormous benefit by itself and this is probably what alienates you against OOP.

    Java is a bad language in that respect in that it forces the programmer to associate every line of code with a class. There are languages that have a light weight approach to polymorphism, for example Clojure is really interesting in that respect. It does offer convenient polymorphism with a bottom-up approach.

    And this is another point to make really: Bottom up vs. Top down programming. A lot of programming tutorials reiterate wisdom of top-down software engineering (sometimes poorly really). However, bottom-up programming really has its benefits. See Paul Grahams interesting essay on this: http://www.paulgraham.com/progbot.html


    • September 3, 2013 at 10:25

      Thank you for sharing this perspective. Others have shared the key importance of polymorphism. Seems that the key to object-oriented programming is different to different people.

      A few years on from this posting I am starting to see the value of object-oriented programming, and may even try it sometime soon.

      If lack of polymorphism in scheme bothers you, the great thing about Lisp of any kind is that you can create your own language out of it: purely function, object-oriented or whatever. However, you’ll have to get to the heart of Lisp first, and in the process you’ll discover some really great things about it. It’ll hook you.


  12. Dev
    April 17, 2014 at 02:04

    Hi bro, I am in a similar position…I just dont get all these abstractions that are so much celebrated and valued in OOP languages. I read in a CSDA text that OOP breaks away from the responsibility of the coder to think about the processor architecture…somewhat of what we do in C,specially when using it for Linux/Unix sys prog etc. BUT heyy thats way lot interesting…isn’t it. Recently I had to take up C# for job related demands, SERIOUSLY I am confused with
    a) OOP concepts being implemented without me finding it(when others can)
    b) Such a huge list of in-built facilities in C#(ohh I hate this the most… I f*cking get confused just searching things)
    c)continuously trying to figure what is actually happening under the curtains of “CLR”

    Thats why I just randomly googled “I hate Object Oriented Languages” to see if I am the only one 🙂


    • April 17, 2014 at 11:39

      I’m glad you commented at this time, because I have been reading about C++, thinking that if I learn more about it then I will understand programming literature better — there are many marks of people who learned particular languages. Many programming languages seem targeted at people who are “converting” from other languages. Many features of particular languages don’t make sense to me without that history.

      Three things have jumped out at me, and I may write a follow-up to emphasize these points, as this is one of my most popular postings. (1) Much of the zealotry I encountered was the sign of inexperience, or “youthful exuberance.” When people learn something really cool, they tend to go around talking like they are the ones who have The Secret. I’ve done this with plenty of my interests. Experts don’t talk in terms of whatever their unique thing is; they talk in terms of the real needs of solving a particular problem, and they just do it in the way they know how to do it, or the best way. This is part of “novice mentality,” something that I plan to write about very soon.

      (2) C++ is not just about object-oriented programming. It’s multi-paradigm and it was meant primarily as a way of importing other languages’ features, combining them with what was good about C. C was portable, but it lacked certain features that were desirable for its purpose (systems programming). What’s funny about this is that C++ was promoted for the same reason that every programming language is promoted for: it’s more natural, it allows programmers more flexibility, it requires less development time, it’s modular. Whether these actually happens comes down to the programmer.

      (3) I have never designed a program in the style that C++ (and most languages) was meant for. I just sit down and write. C is fine for that, much of the time. I don’t plan things out as a directed acyclic graph or a family of concepts. Based on what I’ve been reading, C++ was designed to suit the needs of a much more abstract sort of problem solving. There’s a lot about programming literature (not just object-oriented programming) that I haven’t understood, and I think this is why. I’m going to try to practice better problem-solving and we’ll see if object-oriented programming makes more sense.


  13. September 6, 2014 at 18:31

    I do not get it too and no one is giving me a clear explanation of what OOP is in my college. I`ve been walking a long road with structured programming and OOP for me is very hard and complex and they are demanding it in my college or I fail. =/


    • September 9, 2014 at 10:14

      OOP or fail? That’s pretty harsh. I am starting to get it after reading Stroustroup’s book The C++ Programming Language. Try to get a copy of that and then see if you can get the idea. I understood it a lot better basically as encapsulation. Classes help encapsulate properties. Stroustroup explains this very clearly, imho.


  14. December 17, 2017 at 13:08

    I use a mix of functional programming and OOP. There is a still quite a lot I don’t understand about OOP but I have observed that it is just a different way to approach a problem. For myself, I have found that for the procedures I reuse in other projects, having those procedures as objects help me keep it all organized in my head. When I have a large project I need to create, I find that thinking through it using UML and then creating it using OOP helps me create it more efficiently. If it’s a project I need to collaborate with others on, I find OOP to be easier to communicate and document than functional programming.

    Really it boils down to your own personal preference, how you think, what you are good at, and what your programming goals are. It’s a good tool to have when working with others, but if you just like doing your own thing, then who cares how you do her.


  1. July 8, 2010 at 13:44
  2. July 8, 2010 at 19:13
  3. January 30, 2011 at 13:06
  4. November 16, 2011 at 03:10

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: