Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

All evidence points to OOP being bullshit

This is the second part in a series I’m writing about lessons that can be learned from functional programming. Find the first part here.

Object Oriented Programming (OOP) as an idea has been oversold. The most commonly used languages in use today are designed around the idea of OOP. Extremist languages like Java force you to think of everything in terms of objects. But is Object Orientation (OO) a good idea? Does it have problems? Is it the right tool for everything? Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.

Imperative vs Declarative

The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. — Paul Graham

Procedural programming languages are designed around the idea of enumerating the steps required to complete a task. OOP languages are the same in that they are imperative – they are still essentially about giving the computer a sequence of commands to execute. What OOP introduces are abstractions that attempt to improve code sharing and security. In many ways it is still essentially procedural code.

Declarative languages on the other hand are about describing computation. While a a declarative language necessarily maps down to imperative code, the resulting code often reveals less incidental complexity and can sometimes be much more easily parallelized.


The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong

State is not your friend, state is your enemy. Changes to state make programs harder to reason about, harder to test and harder to debug. Stateful programs are harder to parallelize, and this is important in a world moving towards more units, more cores and more work. OOP languages encourage mutability, non determinism and complexity.

As someone who was initially hostile to the idea that state is the root of all problems, I initially greeted this idea with skepticism. Mutating state is so easy and fundamental in OOP that you often overlook how often it happens. If you’re invoking a method on an object that’s not a getter, you’re probably mutating state.

Nouns and Verbs

Java is the most distressing thing to happen to computing since MS-DOS. — Alan Kay

The typical college introduction to OOP starts with a gentle introduction to objects as metaphors for real world concepts. Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands. Software as a mechanism for directing a computer to do work is primarily concerned with verbs.

OOP programs that exhibit low coupling, cohesion and good reusability sometimes feel like nebulous constellations, with hundreds of tiny objects all interacting with each other. Sacrificing readability for changeability. Many of  OOP best practices are in fact encouraged by functional programming languages.

Inheritance vs composition

Object-oriented programming is an exceptionally bad idea which could only have originated in California — Edsger W. Dijkstra

Inheritance is one of the primary mechanisms for sharing code in an an OO language. But this idea is so problematic that even the keenest advocates of OO discourage this pattern. Inheritance forces you to define the taxonomy and structure of your application in advance, with all its connections and intricacies. This structure is resistant to change which is one of the primary problems software developers face every day. It also fails to model some pretty fundamental concepts.

Further reading

This is far from an exhaustive list of the criticisms leveled at OOP. While I believe the problems with OOP are extensive, I do think it is a valuable mechanism for developing software. But is certainly not the only one. The biggest problem in my mind is thus:

When people overcome the significant hurdle of fully appreciating OOP, they tend to apply it to every problem. OOP becomes the solution, and every problem looks like a nail.

There’s got to be a better way…

  1. John Barker says:

    For the lulz:

    You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you. — Ron Minnich

  2. KD says:

    all evidence points to this article being bullshit.

    even if you don’t agree, you still need to respect it as a concept. while I would never shit on functional programming, you shitting on OOP is just makes you look like a looney cowboy coder.

  3. John Barker says:

    If you read the article, besides declaring upfront that it was meant to be read ‘tongue-in-cheek’ I state that OOP is still a valuable concept in the conclusion.

  4. Paul says:

    You don’t have to respect it as a concept. The entirety of OOP design can be approximated as a list of functions scoped in a closure bound to a publicly mutable context.

    Classes aren’t a fundamental particle of programming. Objects are (sort of), but only because they’re lists in OOP clothing. Mutable (shared) state is the main enemy.

  5. A powerful idea for how to reconcile these ideas is the “functional core” (which may include immutable instances) wrapped in a thin “imperative shell.”

    Destroy All Software has a short screencast with more detail (but costs cash to watch.)

  6. There’s an argument to be made that OO designs done right scale better (along the axis of program size & complexity) than procedural ones, and I wonder whether OO might scale better than functional designs too.

    I’m not talking about the superficial sense in which OO allows one to reason about the problem by forming classes with close association to entities in the problem domain.

    Instead I’m talking about the way that OO done right allows one to make designs such that, when one wants to add to the program, it’s possible to do so by adding new classes in new files, without modifying any of your existing code.

    However, most code written in ostensibly OO languages doesn’t get this right, so there’s a disconnect between the theoretical capabilities of OO, and how it’s commonly practised.

    The writings of Carlo Pescio are the best summary of these ideas I’ve found, especially his example of an industrial pump, and follow up posts discussing the shortfalls of suggestions made in the comments.

  7. Tim Fox says:

    TLDR; “Screwdrivers suck, everyone should use hammers”.

  8. Tom Davies says:

    When Alan Kay said “Java is the most distressing thing to happen to computing since MS-DOS” I doubt if he thought it was too object oriented. At least Java has the ‘final’ keyword. Not really a useful quote in this context, IMHO.

  9. Tim Black says:

    Bad code is bad code regardless of the programming model or paradigm used. Badly written OO code is worse to manage than a well written procedural application. Most so called OO code is really procedural stuff placed in a few classes.
    The power of OO is when its used in the correct way. Under these conditions there are very powerful arguments for its use.
    Its a bit like the argument for C or C++. If you don’t know C++ well enough then stick with C cause you can make a real mess of it in C++ if you don’t really know what you are doing.
    If you just want to write spaghetti in either case then consider a job at a well known burger outlet.
    Remember – any idiot can write code a computer understands but the skill is in writing code that humans can understand as well!

  10. Erik Reppen says:

    Nothing has done more harm to OOP than legions of mediocre Java devs being forced to stick everything in a class no matter what. When everything is OOP, nothing is. I still don’t get the state criticism. You want a banana, you should get a banana. If it’s been peeled, something needs to know that. Ideally the banana.

  11. Önder ALTINTAŞ says:

    Nice article to read especially with the comments below.

    Although I am a new at software development domain, with my limited experience, object oriented design and development is a good way to make everyone in the project life cycle (from product owner to devs) understand the concepts no matter what limits they have. Plus, having control over whole development process seems much more easier. I still have hesitations, but in my work environment, it seems the best way to deal with the “maximum outcome in minimum time” problem which is a motto of small-mid size companies. For bigger companies, I think it is also beneficial to measure the total effort and resource that should be spend as well as to hold the surprises at minimum rate.

    My hesitation comes from this sentence:
    “…I have yet to see an interesting piece of code that comes from these OO people…”

    Although the article is pretty old, the meaning looks more true these days. While innovation is coming from piece of codes, it is easy to kill them to pass reusability or while reusing the old solutions to the similar kind of problems.

    In addition, the technology inflation is an another matter that makes the OOD&D look ugly which I would want to discuss about but I have only 15 letters lef…

  12. Adama says:

    Visual Basic 6.0 (VB6) is doing a better job at OOPs than VB.Net :)

  13. “Object Oriented Programming (OOP) as an idea has been oversold.”

    A more accurate statement would be OOP is an idea that has been hugely misunderstood.

    Most of your objections are to the messy commercial perversion of OOP that originated in the late 90s, rather than actual OOP.

    The central premise of original OOP was to stop thinking like a computer. OOP is not a different way to structure code. It is a new way to think about designing computer systems.

    Programmers don’t like doing that. Programmers like thinking about the steps a computer performs to carry out an action. They like thinking about data. They like thinking about actions that manipulate data.

    So when the mass market got hold of OOP they forced it into a procedural paradigm and, unsurprisingly, found it didn’t work very well. You know have people pointing out that this straw-man version of OOP doesn’t work very well. Well duh.

    If you design computer systems as you imagine they computer will run them, then don’t use OOP. If you do you will create a mess. Use a design paradigm that fits the way you think about the problem, such as structured or functional programming.

    You will of course run into all the issues of scale and complexity that OOP originally was designed to solve. But at least you will thinking in the right frame of mind for the way you imagine the solution space.

  14. sweetp says:

    Love the article and comments. To me, OOP sometimes seems like “group think”; Kool-Aid served up as the modern best practice. The big-picture concept of OOP is easy enough to grasp and sounds great, but when I try to apply the concepts in real world projects I often end up scratching my head, hitting the internet, and finding a lack of consensus. Kudos to the author, it takes balls to publicly question OOP these days.

  15. Richard says:

    When you’ve been trained to think a certain way you will code in that way and resist other ways because it doesn’t feel native to you. I agree somewhat with the article. I was taught to code in JS and it is a functional language and at this point in time OOP has taken over javascript and some people with strong opinions have labeled those who don’t comply as poor coders. It’s really just syntax. It’s not our fault that there are performance issues and other issues because languages were designed poorly. So really people have learned to develop based on how a language forces you to develop. That being said I am learning OOP and I have a love hate relationship with it. who cares??. BUILD GOOD PRODUCTS. I think that is the answer. Communicate well with what you’ve been given… So what if you miss a period or mis-pronounce a word I’m tired of so many developers being all high and mighty with their coding practices aka Code Pharisees. (Good Article)

  16. John Fickin Doe says:

    When the philosophy discussion is over and it’s time to get back to work…smart developers know that object classes only make sense when there are too many functions to manage easily. 1) Start with procedural. 2) Eventually add functions when you find yourself repeating yourself. And then 3) eventually add classes when you have too many repetitive functions. That’s it. The underlying principle is “DRY” (“Don’t Repeat Yourself”) – not procedural or structural or functional or object-oriented. A 5-line program should never have an object in it. A 3-line program should never have a function in it. All this programming paradigm stuff is just half-baked blather from people thinking out loud or trying to sell books. Most PHP programmers use a mix of procedural, functional, and object-oriented. That’s as it should be. Results matter. Not philosophies.

  17. Fritz says:

    John Fickin Joe:

    If you’re just writing small and loosely interconnected scripts, I guess you can choose a strategy of starting procedural, and adding functions along the way as you need them.

    But, if you’re responsible for the code base of large LOB systems, you’ll now upfront that you’ll have to structure your code using classes and objects.

    So, it depends a bit upon the type of programming that you’re doing.

    Personally, I write large corporate systems, with 100.000+ code lines. 99% of the time I start out assuming that I need to structure my code into classes and objects. The only exception is if I write something outside the main code base, such as a DLL wrapper. Then I’ll have the option of writing purely functional or procedural code. But, otherwise, usually not.

  18. Fritze Flink says:

    Nice article. I have been a victim of OO design and programming for over 20 years. It never dawned on me that I am a victim of some sort of Ponzi Scheme of IT but I have always felt bad about the programs I was forced to design since the introduction of C++ in my company in the 90s. I always thought, it’s just me and OO is the law of the land now so it must be me who is having a problem.
    Recently I started to look around and I realized there are more people out there who see things my way and that’s encouraging to know.

    In my opinion, OOP is exactly the opposite of what they promised us. I remember arguments like “OO forces you to think a problem through before you start coding” – The opposite is true. Since it is so easy to imagine everything as an object, you just start coding objects and feel great about how natural it all falls together, but then the objects mutate into hideous abominations and in the end you end up with as many subroutine calls as any other design principle might create, just they are all listed under a class name ( and not necessarily under the one that’s best suited)

    Anyway, I’m only beginning to explore the field of criticism so I have not much to offer other than my personal experience with OO, but I’m glad to read blogs like these to learn more about the discussion.

  19. sam brody says:

    I am starting to think the real divisions are about the end objective of a program (especially when you take into account the type of program) For instance, I love procedural coding in php. It feels quick, responsive to what I want and lets me roll up my sleeves bang on my keyboard to german techno and get my hands dirty. It feels like im working the soil of the earth…just on a keyboard.

    Now, is my code super readable….not really, I run it through php documentor so people can follow behind me. Im I a clean coding scientist…nope..obviously not. I get my concept and hack it out.

    OOP is not as much fun to write in…it feels super convoluted and forced. I do not feel like im working the soil of the earth. BUT…If i want my user to log on with facebook then post to their wall and send an email that will actually make it to their inbox when I certain Boolean test is met…then yea, I would be an idiot to try and write that from scratch like a crazed soil of earth farmer. Then all of a sudden OOP starts making some sense, I can just use that class and this class some other guy built, make my object and call it a day….still…that doesnt mean I like writing with it!

  20. jbotelho says:

    Awesome article man!

    So hard to find someone to criticize this OO philosophy and world view. Good to hear this.
    My opinion:

    The problem is deeper, is materialism, son of evolution; and as it usually does (the evolution philosophy, it limits potential, capacity, understanding, performance in the many trees of the science forest, that’s what a wrong paradigm(philosophy) does.

    Not everything is an object, it’s wrong (Of course it gets deeper). We write code because we need it to perform a function in the real world, as everything in nature has its purpose, everything we do also, even if it’s just our nonsense sometimes.

    So any paradigm, any code, any tools, they all are written to perform functions. Forcing concepts to be categorized as objects ain’t realistic.

    • James Woods says:

      in saying that code is always written to perform functions you are forgetting what the functions will be working on. They will be working on some data structure that itself has meaning to the system’s users. Putting these together the functions will be the verbs and the data structures will be the nouns. This is an entirely realistic way to model a system, whether you use on OO language or not. OO simply seeks to reinforce this practice of clustering methods with the data they are best associated with in order to maximise the cohesion of the software.

      • Param says:

        It doesn’t always work though. For example, I want to write a function to sum a list of numbers. Where should the sum() function reside? It can’t be added to the List class because not all lists can be summed. In the end, I will be forced to create a “utility” class like Lists and put the sum function there. That’s not really object oriented.

        There are a lot of classes in the Java SDK that have just static methods – Math, Collections, Arrays etc. That’s because there’s no proper way to put these methods “alongside the data”. For me, these classes serve the purpose that ‘modules’ do in procedural or functional languages – i.e. to group together related functions.

        TLDR: OOP can’t model everything properly.

  21. T. says:

    The problem with articles with cheap-attention-grabbing-trick titles such as this, is that discussion usually starts and ends with that title alone.

    And sure enough, you’re not saying anything even remotely interesting or original.

    OOP becomes effectively “bullshit” (sigh) when it’s done poorly – with a procedural way of thinking, for instance.

    …Just like FP can seem “bullshit” to some OOP programmers not fully understanding it (I just went through another article calling FP programmers “crackpots”).

    Is the possibility of having both OOP and FP in the toolbox, and using one or the other depending on the problem domain, too hard to grasp? Is a balanced point of view too much for zealots on both sides to handle? Really?

    Here’s an advice: next time, work more on substance and find a decent title.

    • Jay says:

      “OOP becomes effectively “bullshit” (sigh) when it’s done poorly – with a procedural way of thinking, for instance.”

      No OOP doesn’t effectively become bullshit with procedural thinking. OOP effectively becomes bullshit when programmers decide: lets sit down and draw up one huge complex MONSTER design of a system and then implement all those complexities creating an unmaintainable mess, instead of just prototyping, seeing what we need and gain a true understanding of how to accomplish a task and then go about implementing it iteratively.

  22. I completely agree with the author. I know where he’s coming from. I had similar experiences in the real world. Although OOP is a neat concept, when in practice either concept is dependent on how well the code is written. Basically the quote about well structured spaghetti code is spot on!

    Especially coming from the “web” world, I see so many wrongs with today’s back-end development practices. It’s simple web pages that have turned into OOP monsters. Customization is out the window! And now, it has started a movement into the front end with angularjs. Yikes! Frameworks and OOP. Two of the things the web never needed before, and all of the websites did just fine, didn’t they?

    If non OOP practice was really that bad, it would have gone out the window only a few years after OOP practices came out. I believe it’s a real world validation that standard FP is not only still around, but praised by many experienced web devs. It’s a strong validation to me that I’m not going crazy just because I won’t join a new religion…

    • Jay says:

      The problem with modern day websites is that they are trying to be more than just websites, they are trying to be full blown “web applications” trying to replicate behavior of actual programs.

      Originally, in the early days of the Internet, a website was just an HTML file filled with styled text (using the standard CSS background/foreground/font/face etc. styles) and maybe a few images here and there. If you needed to get from one page to another, you had good old hyperlinks which tell the browser to load the new page, and the browser did a pretty good job of it, it gracefully handled all of the countless network errors which could arise, allowed you to reload the same page if it failed to load, and even saved your history so you click on the back button if you accidentally make a mistake as to click on the wrong hyperlink, allowing you to seamlessly return to the page you visited previously. The webpage content was typically managed by a server side script such, as PHP or Perl, which pulls the requested content out of a database, formats it in HTML and sends it to the client, it also allows the webpage content to be updated from remote. Back in the day webpages were usually faster than they are today even though the Internet was MUCH slower than it is today.

      Then Javascript happened, Javascript allows webpages to be more than just styled text and a few images here and there, Javascript allowed scripts to be run INSIDE the browser, this allowed webpages to make text and images fly on the screen, allowed windows containing ads to popup, allowed mouse followers, and any other BS you can think of. Most of this is actually quite useless and the only effect it has is bloating the webpage, making it slower to load, allowing buggy scripts (they are usually quite buggy) to freeze the browser forcing you to force quit/kill process it losing all the webpages you had open, if the browser didn’t freeze it certainly slowed down overall. There are use cases when Javascript is actually justified such as online games, WYSIWYG editors and any form of dynamic client-side interaction which is absolutely crucial for your application, but most of the time Javascript is abused, and webpages could easily do without all the gimmicks they have.

      Then Ajax happened, this allowed Javascript pages to dynamically reload content without having to reload the page, since Ajax calls happen in separate threads the current page is not frozen and the user can interact with it whilst the dynamic content is loading and without using bulky, clunky frames. In theory this is good, in fact there are a number of scenarios where this behavior is actually required, when the content you need is a tiny fraction of your total webpage content and is constantly updated, however once again it is mostly overused and abused. A lot of modern websites try to use Ajax to replace hyperlinks (because they are just not sexy enough), i.e. instead of just reloading the whole page, they reload the content (which is most of the page) and insert inside the main “” element of the page. In theory you may think this is a good idea but it is actually a very very bad idea, first of all the scriptwriter has to handle every possible network error that can occur and usually scripts do not handle errors as gracefully as the browser, the scripts either crash and halt completely leaving the webpage unresponsive (usually with some loading circle in the centre) forcing you to reload, a network error could be something as simple as a momentary loss of your wifi connection or your IP address being reassigned by your ISP, which a browser would easily recover from. Using Ajax to replace hyperlinks also renders your back button, and browser history useless, I have often been surprised clicking back expecting to go back to the content I previously visited on the same page only to end up in Google or wherever I opened the webpage from, same problem happens if I have to reload an unresponsive webpage due to a buggy Ajax script. Ajax has the potential to spawn so many threads that it can crash the browser and sometimes even the entire computer (I’ve had my slower less powerful laptop overheat with the fan on full speed after viewing a few webpages). Ajax also allows infinite scrolling, as in Facebook, Youtube and Tumblr, which is a horrible idea and obviously designed by people who have no idea how a computer actually works and where content is actually stored (IN MEMORY), infinite scrolling just appends new HTML content to an existing tag eventually resulting in so much content that the browser runs short on memory to store it slowing down not just the browser but the entire computer.

      I am not against Javascript or even saying that the language is a bad language which should not be used however it should definitely not be used as much as it currently is. When I was in the web-development business the attitude towards Javascript was if you have to use it, use it sparingly and only if you REALLY have to, kind of like operator overloading in C++ or inheritance in OOP. Many of today’s webpages can be rewritten solely in HTML/CSS backed by a server-side script.

  23. Jay says:

    “Procedural programming languages are designed around the idea of enumerating the steps required to complete a task.”
    “Declarative languages on the other hand are about describing computation.”

    The problem with these two statements is that they are fundamentally the same. Describing computation is still the idea of enumerating the steps required to complete a task, albeit at a higher level. A commonly used statement to explain functional programming is that “In imperative programming you tell the computer how do to something, in functional programming you tell it what to do”, unfortunately this statement in itself does not make sense as in every programming language you are constantly doing BOTH, even in the lowest level assembly you are still telling the computer what to do, you don’t tell the computer how to add two numbers, you tell it to add two numbers. If we go to the other end of the spectrum: a high level functional pure programming language such as Haskell you are in fact telling the computer how to complete a task, that’s what your program does it completes a specific task, you obviously don’t tell Haskell “build me a program which does X while I sit here and sip my coffee”, you tell it do Y, do Z, do W, etc. which eventually becomes your program a sequence of steps to complete a given task.

    Yes you could state that languages such as Haskell, ML, Clojure, etc. are “higher level” languages and have “higher level” features than Java/C/C++/C#, features such as anonymous functions (even though C++ and C# also have them), functions as first class objects (oops did I just say object well that’s the phrase used in the FP world anyway), lazy evaluation, lazy computation of sequence operations such as map, reduce/fold, persistent immutable data structures allowing structure sharing to avoid excessive copying the main feature which makes programming with immutable data structures (functional programming) possible, however it is wrong to state that they are declarative languages distinct from imperative languages. A declarative language is one which is comprised of set of declarations, nothing else, i.e. you can’t and don’t tell the computer to do anything, a declarative language is useless in itself, it serves a purpose to define declarations which will be used by another language. An example of a purely declarative language would be CSS (Cascading Style Sheet) in it you don’t give any instructions to the computer, you simple declare styles which will be used by the HTML and JS in your webpage, you can’t create CSS scripts which dynamically change styles or dynamically determine styles based on some other parameter, you can only make declarations.

    Functional programming is Imperative programming, NOT declarative programming, it is indeed a high level form of imperative programming and abstracts away a lot of imperative details such as explicit for loops over data structures and provides a host of features with a form of program organization which make programming easier and safer but it is still imperative you are giving the computer a sequence of instructions to complete a specific task.

    “OOP languages are the same in that they are imperative – they are still essentially about giving the computer a sequence of commands to execute”

    OOP is a paradigm, not a class of languages, one which is not clearly defined or understood. What exactly is OOP few people can answer that if anyone, it is a magic term used to promote a language. In the Java world OOP means classes and lots and lots of classes so most people think of OOP as classes, however that is not a good definition as Javascript does not have classes, OOPS (pun intended) but is object oriented (it achieves it using functions). If we think of OOP in terms of objects, well we first have to define what an object is, an object can be defined as an entity (occupying memory) within a program, and with a set of methods (really glorified functions) operating on the that object. This would make the commonly used data structures found in high level languages such as Haskell: lists, tuples, hashmaps/tables/dictionaries (functions) objects, your built in Bignums are objects too, in-fact nearly every language is built around objects, thus every language can qualify as object oriented, obviously not a good definition. If we look at the main principles of OOP, they are reusability, encapsulation and polymorphism, reusability can be achieved by having many functions performing commonly used functionality, encapsulation: contrary to what most people think encapsulation does not necessarily mean mutable state, indeed finding the area of a shape is encapsulating the details of how the area is calculated or how the necessary information regarding the shape is stored thus you can use the shape without knowing how it works, also those multiprocessing features encapsulate the details of threads as for polymorphism, functional programming is built on this.

    My understanding of OOP is making use of objects as in blocks of memory which can be treated as a higher level datatype abstraction such as lists, vectors, hash maps with necessary methods, or functions if you, which allow me to use and manipulate (I do not mean mutate) those structures encapsulating all the details of how they are stored, how they work etc. In other words non-OOP programming according to my definition would programming using primitives and pointers to memory only which is obviously low-level tedious and error prone.

    The problem we currently have in program is not a specific problem of the OOP paradigm but rather a tendency of making overly complex designs (i.e. deep nested dependent structures) overall resulting in a bloated, slow, unmaintainable and bug-ridden system, imagine if all the crappy Java programmers (I don’t mean that all people who program in Java are crappy just referring to those that are) switch to Haskell, they will quickly create a complex unreadable, unmaintainable mess.

  24. Andrew Clunn says:

    The notion of predefined structures that are able to define functions specific to their own data is a useful tool. That it requires an entire language to become object oriented is dubious. The author is stating what many know to be true, but almost no one who has invested time into learning something want to believe that their knowledge is in fact useless (and indeed from a purely practical standpoint it isn’t since object oriented languages are so common). Of course all the real excitement is around scripting languages these days. First it was ruby, then python, now go. People don’t want a needlessly obtuse language then lends itself to inheritance hell. Object oriented programming languages have had their run, but they’re definitely not the future.

  25. Jon Forrest says:

    “with all it’s connections and intricacies.” ->
    “with all its connections and intricacies.”

  26. […] >> All evidence points to OOP being bullshit [] […]

  27. Dylan Vann says:

    State leads to bugs, so it should be kept to a reasonable minimum.

    If a program does have state it should be organized carefully, since it’s so dangerous. Object orientation is a way to organize state.

    I’ve been working with a lot of web code. I get the impression lots of JS developers don’t really understand or like object oriented programming, so instead of OOP code with the state on a few objects you end up with state all over the place. It’s in globals, it’s in the HTML, and it’s in closures. It’s everywhere!

  28. > Object Oriented Programming (OOP) as an idea has been oversold. […] Extremist languages like Java force you to think of everything in terms of objects.

    Yes, OOP has been oversold. But that’s not the problem of OOP; that’s the problem of incompetent programmers who are trying to use one tool for everything. Of course what Java doing is extremism too (also, see the amount of incompetent programmers in each language… Java is considered an “industrial” language, so it’s perhaps only C and C++ that has more utterly incompetent users than Java; people want to be rich.) But nobody said you have to use Java! In fact, I think you should not use Java. Having to write an entire class just to possess a main function? Stupid! There are better OO languages that don’t *force* you into the OO mindset, e.g. Objective-C or C++.

    > State is not your friend, state is your enemy. Changes to state make programs harder to reason about […]

    Except when it’s the declarative approach that’s harder to reason about. What’s easier to understand, printf or the IO monad? If you want a non-trivial (!) database query, wouldn’t it be easier to understand a procedural program written in your own favorite language than a highly convoluted SQL statement?

    > Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands.

    Again, that’s not the problem of OOP, that’s the problem of design patterns. Just like you don’t have to (and shouldn’t) use Java, you don’t have to (and mostly you shouldn’t) use these “design patterns” either. Most of the time, they turn out to be artificial constraints on the implementation, taking away the programmer’s freedom and creating code bloat. They make things overly complex (e.g. disguise verbs for nouns, as you pointed out), and that’s where the problem lies.

  29. […] that all might not be well in the kingdom of Object Oriented programming. (see also this video, and this post, and any of these articles). JavaScript is everywhere (see item #3 below) and if we teach it […]

  30. Matt in Houston says:

    In the web development field, OOP has become a runaway religion in the last decade. The more OOP you know, the more salary and responsibility you can negotiate in a job interview. Most hiring managers will screen out candidates who don’t know OOP well or who haven’t used it extensively. Sample code submitted for assessments will be deemed unacceptable if it’s not OOP. Any opinion expressed doubting the alleged superiority of OOP in an interview will cost the candidate a job offer.

    And this carries over into coding standards and code reviews for everything except legacy system maintenance. Procedural programming is scorned as “wrong”, “archaic”, “bad practice”, and “amateurish”. Don’t be caught writing it or you may receive a negative performance review. You can wear a ripped t-shirt into work with the words “fuck the world” printed on it, but if you write a block of code not wrapped in a class definition, you may be terminated for it.

    And this carries over into the market for software. If an existing system is written in mostly procedural code, that alone is usually justification for the engineering teams to deem it “outdated” or “obsolete”. The developers don’t want to be caught dead coding it; their future job opportunities would be jeopardized by it. You can’t find off-the-shelf software tools providing any type of code other then OOP. Contractors won’t write in anything other than ?OOP.

    So with all this pressure to conform to OOP and eradicate procedural programming, we see lots of faking, lots of foolhardy experimenting, lots of overuse, lots of forced rewrites, and lots of half-baked ideas. In short, we see bad, confusing, inappropriate OOP everywhere.

  31. Franky says:

    When I see professionally designed OOP software, especially in C++ I kind of faint every time. It is a nightmare. I’ve been working with the Unreal Engine for a while now and while it is a big and powerful engine, I am still not able to understand a thing that’s going on under the hood. Ok, like I said, it’s huge, but templates within templates certainly don’t help.

    My own application is a client server game and while the client has to be embedded in Unreal and therefore has very little freedom of design (one has to do it their way or else), the server is designed in C++ without a big third party library.

    What I realized is over the years is, that there are very few opportunities to really apply OOP concepts. About 90% of the server consist of singletons that provide certain services or procedural code disguised as C++ classes. The rest are things like characters, items or other minor things that benefit from inheritance, but frankly ,there is nothing that could not be done in, say, Pascal or Ada with nested records.

    The only useful features of C++ in my eyes are templates when used in a library like the STL to provide containers, and lambdas, which we mostly use to put code into datatables which allows us to call the new operator from a table based on an enum, thus effectively providing an old fashioned factory function as datatable.

    A major problem with OOP in my eyes is the inefficiency that objects pose through multiple lookup tables when it comes to memory cache misses. There is a great article, I think by sony somewhere that explains this in detail and once you read this, you really don’t want to use inheritance for speed conscious projects like games.

    PS I found the link, it has been removed from Sony’s webiste but it’s buffered elsewhere:

    • Franky says:

      What I forgot is this: From my experience with this big project, the unity of code and data is a very bad idea. Encapsulation of data as it happens in C++ classes often prevents sharing of data across processes. For instance we have a client, a main server and a spatial server that handle different aspect of the game. Sharing of data can not happen through traditional classes since code that is referred to in a class method on the server may not exist elsewhere. So our solution is to expose data in form of structures and then embed these structures in C++ classes which then perform the methods.

      A final thought on this: while it will most likely cause some people to get a stroke, it is not so heretic to expose data. After all, we’re not writing code for a war zone with hostile programmers all around trying to attack our data. If you can’t trust your fellow programmers to not change a data element when it’s comment say”don’t alter” then you have a bigger problem than missing information hiding.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *