For years, I have been doing Algorithmic stuff, writing scalable data structures for internet search, for example Randomized Binary Search Trees for Auto Recommendation, BitMaps, Wisdom of Crowd based Algorithms using Graphs, writing some interesting Machine Learning Algorithms like Clustering, Anomaly Detection, working on Information Retrieval stuff and so on

There is a common thing in the things that I have mentioned above. All the above stuff;each if coded in a language like C++ requires handful of classes. I mean they are interesting problems but they are not complex in terms of heavily loaded Object Oriented stuff. I have never used Inheritance, virtual stuff etc. Though I have heavily used Generic Programming, Templates and so on.

I love C++ (- Bulky OO stuff, As I like what Joe Armstrong's, creator of Erlang says, In OO World if you ask for a banana you get a big jungle alongwith gorilla holding the banana). I enjoy coding in other languages like Java, Python too.

Now my question is since I am enjoying the kind of projects/Algorithms I am working on do I need to really learn OO stuff, will I be a better coder/designer just by using the stuff like Inheritance, Dynamic Polymorphism (virtuals)? OR can I move to the world of Functional Programming (I have not done it till now) which attracts me more as I can just focus on tasks/algorithms and not let Kingdom Of Noun based OO stuff, has-a, is-a rule me?

In short will/can OO stuff help me at all for the kind of projects/Algorithms that I have mentioned above?


One extremely interesting link to add here:


closed as not constructive by user7519, ChrisF Feb 28 '12 at 22:02


  • 25
    Object-orientation is the most widely-used programming paradigm today. Ignore it at your peril. – Robert Harvey Feb 28 '12 at 16:28
  • 5
    <sarcasm>Nah, don't worry about it. C should be enough for you.</sarcasm> – Otávio Décio Feb 28 '12 at 16:29
  • 2
    Related/possible duplicate: programmers.stackexchange.com/questions/7126/… – Adam Lear Feb 28 '12 at 16:34
  • 16
    Of course OOP/OOD is overrated. This trivial model is only usable for narrow set of problems. But you should not ignore it - otherwise you'll end up using the wrong tools for that rare and narrow areas where OOP really shines. – SK-logic Feb 28 '12 at 16:44
  • 13
    Linus Torvalds, is this you? – Jesse C. Slicer Feb 28 '12 at 16:50

11 Answers 11


Object oriented programming is really good at hiding your complex fancypants mathy stuff behind easy to understand words and making it easier for the lessers among you to actually use the things you've written. It doesn't replace functional programming ... it just gives you a really easy way to switch out implementations or add behavior.

In your Randomized Binary Search Trees example above, what if you were given the requirement that on April Fools Day, the Randomizer was replaced with an order-by-distance-from-three-stooges. It's really handy to create StoogeBinaryTree : RandomBinaryTree and override the protected int GetSortOrder (Tree a, Tree b) method, so on April 2nd, you can switch implementation back to the RandomBinaryTree without having to have changed any of that code.

In one simple example, I've shown both adding tiny sliver of behavior and switching implementation...

  • 14
    This is not OOP, any decent module system would do the same (and, likely, in a much simpler way). See SML 1st class modules for example. – SK-logic Feb 28 '12 at 16:45
  • 4
    @SK-logic: And modules and OOP are significantly different how, exactly? – DeadMG Feb 28 '12 at 16:57
  • 12
    @DeadMG, there is no BS about states and messages and inheritance in the definition of any decent module system. Only incapsulation, plus a lot of useful math (I know you're going to faint at this point). – SK-logic Feb 28 '12 at 16:59
  • 2
    @SK-logic: My OOP systems don't use messages or inheritance or excessive state. They encapsulate, and then if I need to, they can encapsulate at run-time as well. Other people may do theirs differently, of course, but that is their choice, and not to do with OOP. – DeadMG Feb 28 '12 at 18:19
  • 3
    @DeadMG Then what's the difference between an object oriented language and one that isn't? In what way are for example Haskell or Erlang not object oriented if all that's required for object orientation is a module system? Or are you saying those are object oriented languages? – sepp2k Feb 29 '12 at 5:04

If you are going to do FP still with languages like Haskell and Erlang that do it well, there is no need to drink the OOP cool-aid. FP Is very powerful and can do a lot even in the real world

That being said, learning an OOP language would not be a bad thing. Understanding multiple ways to program and several methodologies will work in your favor. Plus if you move from Haskell or Erlang to Java you can wonder how in the world anyone can work without a REPL and lambdas.

  • And it should be mentioned that languages like Clojure allow for OOP but yet don't constrain you to being class based. That is, Clojure supports polymorphic functions, interfaces, etc. all without the need to create a class (at least not the way C#/Java define it). – Timothy Baldridge Feb 28 '12 at 19:36
  • Joe Armstrong argues that Erlang is more OO than C++ or Java every will be, don't be dogmatic about these things, or you will get bitten by it. Click the link @ Is Erlang Object Oriented? – user7519 Feb 28 '12 at 20:59
  • Oh I'm not, hell I wrote a book about Erlang (shop.oreilly.com/product/0636920021452.do) but when people talk about OOP Erlang is generally not what they mean – Zachary K Feb 28 '12 at 21:25

It seems like you have only been focused on solving a single problem at a time, i.e. writing algorithms. But consider how you'd write a GUI application, for instance, or some other huge application which possible requires you to use a lot of your algorithm. In that case, knowing OO will be essential, since it'll help you simplify your code to make it more readable and easier for other developers to use, e.g. by creating a library that could be a loaded as an object.

One of the most important design patterns in Object Oriented Programming is the Strategy Pattern, which in the above scenario also will help you greatly. Consider an example where the user would present you with input on which you'd allow the user to perform an algorithm. This could easily be a messy if/else or switch/case construction. By creating a common interface for your algorithm and using Strategy Pattern, your code would be much more flexible, readable, easier to extend, and thus easier to maintain.

  • What do you have to say about functional languages that implement the strategy pattern very elegantly (one could argue, more-so) without objects? – Steven Evers Feb 28 '12 at 20:16
  • 4
    -1 For assuming that 1) large applications are impossible without OOP, and 2) that library loading is somehow tied to OOP. Read up on multiple dispatch (and the expression problem), and you start to realize that Java/C#/C++ actually make many tasks harder by placing unneeded restrictions on the programmer. – Timothy Baldridge Feb 28 '12 at 20:25
  • 1
    Please tell me how a library that could be loaded as an object is any better than one that's not loaded as an object? – aseq Feb 28 '12 at 21:28
  • @SnOrfus I'm advocating for OO, because that's the world I'm most familiar with. I'm not familiar with functional language strategy pattern – kba Feb 28 '12 at 22:34
  • 2
    "strategy pattern" That's the one thing that ticks me off more about OOP than anything else. Why does everything have to have a pattern? The only reason that things like the visitor pattern had to be invented was that the language being used was so constrained and complex, that it was impossible to iterate over a datastructure without a pattern. Remove the insane complexity of modern OOP languages, and suddenly patterns as simple functions. Patterns are simply a way of making OOP sound like it has a clue what its doing </rant> – Timothy Baldridge Feb 29 '12 at 14:18

Object-oriented approach became successful because of one crucial aspect: it lets you tackle systems of significant essential complexity without introducing too much accidental complexity. This can be almost ignored when you work on homegrown systems, but becomes very important when you build large-scale systems.

The key elements of the object-oriented approach can be explained to a programmer with extensive exposure to procedural programming in a matter of a few days, which helped the technique gain popularity quickly (this is not to say that you can become an expert in a couple of days: it's similar to learning chess - you can learn how to move your pieces in under ten minutes, but it takes years to master the game).

Functional programming techniques are gaining more importance with the introduction of language support for them into mainstream languages (lambdas and anonymous delegates of C#, lambdas of C++, and even anonymous classes of Java, to a certain degree). It is very helpful to understand these techniques, but they are designed to address more localized problems on the tactical scale. Object-oriented techniques, on the other hand, remain relevant on the strategic scale, especially in the context of larger teams.

  • 3
    Whereas I appreciate the sentiment expressed with regards to complexity, sadly in practice the opposite is true. OO languages have a knack for introducing unnecessary bloat and complexity. That's often not the language's fault. But I believe that if a technique is prone to cause so many people to use it incorrectly it may be somewhat flawed. No matter how nice it sounds in theory. – aseq Feb 28 '12 at 21:34
  • 1
    +1 for dasblinkenlight and I disagree with aseq. In particular, I think that OO maps closely to what's required to do any event-driven GUI, and since there's a lot of activity in UI, there's a lot of activity in OO frameworks. Do a UI without an OO framework, and you'll actually end up building something a lot messier (see X11 Xt); that essential complexity is still there, without the framework it protrudes in horrible ways. Use the right tool for the job. When an unskilled practitioner uses the wrong tool, do you blame the language or the practitioner? – Liudvikas Bukys Feb 28 '12 at 21:59
  • @aseq "But I believe that if a technique is prone to cause so many people to use it incorrectly it may be somewhat flawed." Looking at the raw numbers is misleading because different technologies attract different number of practitioners. Percentages would be somewhat more meaningful, yet they are not readily available. Moreover, barriers to entry and the structure of non-technological incentives keep out practitioners of different degrees of quality, so even percentages may not give you a complete picture. – dasblinkenlight Feb 28 '12 at 22:00
  • 1
    I don't see how functional programming is not "strategic". It is, if anything, better than OOP for larger scales because it reduces coupling and complexity and lets you work at a higher level of abstraction. Also, there are some very nice techniques for building UIs in a purely functional way: check out "functional reactive programming". – Tikhon Jelvis Mar 2 '12 at 4:42

Do functional programming, it will be a very good experience for you, even if you decide not to continue. As you can read out of some of the answers here, many people don't even know what it is.

Functional languages concepts, eg lazy evaluation and referential transparancy, are a very very good thing to learn. Especially if you like recursion.

for example:

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

is a very simple haskell function that recurses through a list and calculates the lenght. If you are interested in numbers bigger than long long and want to use infinite Lists and other fancy stuff, give functional programming a try.

  • 2
    It's also a stupid (manually traversing instead of using pre-built abstractions, and inefficent) way to implement length. A different (more efficent and closer to how nontrivial FP programs are actually written) way might be calling some fold with start value 0 and step function acc -> acc + 1. Alternatively, sum . map (const 1) reads nicely. – user7043 Feb 28 '12 at 17:49
  • 1
    @Giorgio No, the function is not tail-recursive. And even if it was, in languages like Haskell that's only tangibly related to efficency and stack usage (one has to avoid building large thunks; neither this nor a length built atop the non-strict folds do this). – user7043 Feb 28 '12 at 18:25
  • 2
    @Jordan: Except that in Haskell, values cannot be modified, and not all lists have a (finite) length. – Jon Purdy Feb 28 '12 at 18:29
  • 3
    @WalterMaier-Murdnelch Yes, the list will have to be traversed eventually and one has to understand what happens under the hood. But that does not make abstractions useless, quite the opposite. I could write SQL queries (over Yesod's persistent), error handling (over Maybe/Either), state juggling (over State), tree traversals (over Map/Set), etc. but describing my intent in terms of higher-level functionality is better in pretty much every way, and thus also what FP does in practice. – user7043 Feb 28 '12 at 18:30
  • 1
    @Giorgio In strict languages, which are still the norm, it is - though it also depends on the compiler caring for this optimization (Python, despite some urban mythos, is not much of a functional language and does not optimize tail calls -- Lua OTOH does). But as soon as you get non-strict (most prominent example: Haskell), the rules change. You can be tail-recursive and still get a stack overflow because you've built a huge thunk (a million stacked integer additions deferred due to laziness), or (non-tail-)recurse wildly and get along fine. So I wouldn't take this rule as gospel. – user7043 Feb 28 '12 at 18:45

As others have said, object-orientation is the dominant paradigm in industry. You've said that you've worked mostly with programs that can be addressed by a handful of classes, but in an industrial application there are hundreds or thousands of use-cases that need to be addressed and object-orientation has proved a very reliable and broadly comprehensible way to structure such large codebases.

You talk about functional programming, which is a solid contender for The Next Big Paradigm, but FP is not yet familiar in industry. Especially as you are a C++ programmer, you should know that industry can be conservative and the C/C++ world, with its emphasis on performance, is a place where the imperative nature of hardware is seen as a very real consideration. In general, embedded systems programmers are extremely skeptical of FP, in my experience.

Even if FP does become a more dominant paradigm in industry, it is certainly the case that it will succeed in the form of object-functional hybrid languages such as F# and Scala and not in the form of "pure" FP languages such as Haskell.

All of which is to say that, yes, object-oriented "stuff" is important to professional codebases and your career.


OO gained traction because it was a big improvement for handling complexity, as before it structured/procedural programming also was.

The benefits of using OO increase as the size of the project increases. For a 1KLOC program, it doesn't matter much which paradigm you use, all of them will work OK. But for a 200KLOC+ program, there's simply no viable competition for OO. That doesn't mean you can't write a 200KLOC program in C, just that you'll have to be a lot more disciplined to avoid ending up with a mess that no one (not even you) can understand. That doesn't mean that OO will prevent such mess, just that it'll make your life easier in order to prevent it.

Functional programming is a paradigm that somewhat deviated from the previous pattern, because it didn't come to help handle even more complexity than OO did, but to address a different sort of problems: parallel programming. That was the first time, also, that a programming paradigm attempted to do so: all the mechanisms that existed before in OO and/or SP/PP were not part of the paradigm, but just OS entities (threads, mutexes, etc.) encapsulated according to the paradigm rules.

In that regard, FP is a lot more natural than the others, but that comes at the cost of reversing the way we usually think about the problems. And due to that, it has a limited capacity to handle the very same complexity at the same scale that OO does.

My guess is that this will limit the adoption of FP in the near future to very specialized systems, in general not much big, or specialized sections of bigger systems. And the rest will still be made using OO. Which of those you plan to develop (or learn about the development) will determine what should be your learning focus, IMO.



Arguably, templates are simply a different form of OOP. Virtual functions and explicit inheritance have a specific use case- run-time, binary interchangability. Templates are compile-time interchangability. However, at the most basic level, they offer the same feature- abstraction over any type which offers the correct interface. Over-use of run-time inheritance is a significant code smell, and in this case, I agree with you- it simply isn't needed for much of the time.

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

These two snippets are effectively identical, even though one uses templates exclusively and the other uses run-time inheritance and classes as it's implementation. They both abstract over the function you're calling. This is trivially obvious when you substitute T for std::function<void(int)>, for example. The only difference is the time at which that abstraction is made. The template version excels for functions, and std::function is generally better off as member variables. You don't want to have to create a new class every time you want a new callback.

OOP is not particularly well-suited for algorithms. It is more intended for large-scale constructs, breaking down the pieces of the program. If you are writing a specific algorithm operating on specific data then it's unlikely you will need classes.

It's easy, and it's great, to compose algorithms of functions. However, as soon as you get beyond that, then classes emerge as the dominant method.

  • 9
    Wow! Templates are a "form of OOP"? You've made my day, dude! – SK-logic Feb 28 '12 at 17:01
  • 4
    Templates are for Generic Programming. I dont think it is right to say that templates are simply a different form of OOP. Hope Alex Stepanov is not reading this :) – Yavar Feb 28 '12 at 17:13
  • As I've demonstrated, the two functions are effectively equivalent and have the same abstraction. It simply occurs at a different time. – DeadMG Feb 28 '12 at 17:39
  • 4
    The C++ community today uses template meta-programming for things done earlier in a more OOP-way. Nethertheless I would not call this "a different form of OOP". Especially the example above I would call "a C++ way of using functor objects as a special form of functional programming", which is quite not a typical OOP solution. – Doc Brown Feb 28 '12 at 17:55
  • 4
    They overlap in some features, right. That's because they're both useful, so there are inevitably some things they both do well. But that does not show that they're isomorphic all the time, and it does not show they're equally useful (e.g. succinct and efficent) for all problems. A purely functional linked list also shares some features with dynamic, over-allocating arrays - they're both ordered collection, they can be created incrementally with reasonable complexity, they support stack-like usage (push/pop/peek) well, etc. but differ widely, conceptually and in numerous real applications. – user7043 Feb 28 '12 at 17:57

Yes, it is important, for this single reason: understanding OOP makes you a better programmer. As a rule of thumb: understanding always makes you a better programmer.

It should be noted that neither is-a, nor classes let alone inheritance have anything to do with OOP. What OOP is really about is decoupling through indirection, as formulated by the dependency inversion principle. One can argue that this is also an important aspect of FP. If study both OOP and FP, you will increasingly become aware that they are actually two sides of a continuum. The broader and deeper your understanding of it, the better you will become.

To get an understanding of OOP try Io and maybe Smalltalk and Ruby.


In the development world, languages are tools, programming paradigms are tools, and libraries are tools. The more tools you have, the better able you are to select the right tool for the job. So that would argue for you to learn OO, AOP, and Functional programming - as time permits.

The development world keeps growing larger and larger (in terms of languages, frameworks, etc), so you can't expect to learn everything. However, the goal of all these innovations are to help developers become more productive (speed of development, and reusability), and to make code more maintainable (ease of understanding, ease of extending and modifying).

The best thing you can do is to do targeted, continuous learning, in the hope that something new you just learned helped you complete something better and faster in a way you never expected.


I have been reading the Steve Jobs book and in there is a story about how Steve saw SmallTalk at the Xerox PARC labs. That was one of the earliest OO languages. Without OO it would have been horrendous to develop something like a Graphical User Interface (GUI). With all the asynchronous input and being able to jump from task to task while working with one "Object" or another.

So while you can do a lot with a functional language and it definitely has it's use cases. When you start dealing with more complex systems that interact more with real world problems you find OO to be a superior design.

  • the first Macintosh GUI framework ( Toolbox ) was a hideous morass of C that makes Win32 look sane by comparison. OO didn't come into the Mac world until the switch to OSX! This is a terrible analogy and historically misleading at best. Wings3D is written in Erlang and has a very rich GUI and is about as "real world", complex and practical use case as you can get. – user7519 Feb 28 '12 at 20:53
  • It does re-enforce how functional programming was not a good fit then doesn't it. (I haven't finished the book yet, interesting how they didn't choose to use one of the many advances the Xerox team had going, it sounded like the Xerox team was way ahead of it's time) – Bill Leeper Feb 29 '12 at 16:29
  • You do realize that Erlang is a functional language and Wings3D is a very advanced and complicated GUI that contradicts your assertion that functional programming isn't practical and OO is better, which it isn't, not unless you don't comprehend Functional theory. – user7519 Feb 29 '12 at 18:35
