Arguments Against Oop

Summary of Criticisms Against OO

As agreed in AcceptableCriticismOfOoOnWiki, below is a list of criticisms raised against ObjectOrientedProgramming. The opposing twin of this topic is BenefitsOfOo.

Note that not every critic will agree with all of these, nor will all OO proponents agree with all the characterizations of OO given here. This is simply a collection of criticisms put forward. To keep this page clean, please put debates in the sections below, rather than embedded in the list itself. (See PageAnchor "replies") I moved the longer ones below, but left some short ones in place. [EditHint: somebody rearranged the replies into a single topic for pro and con replies and it's now very confusing and very long. (I'm angry about it.) Needs a rework.]

• Inheritance - The real world does not form and change in a hierarchical way in some domains. Trees may be mentally "catchy", but they are too artificial to bend well with change and new details. See LimitsOfHierarchies, ThereAreNoTypes, SwitchStatementsSmell. Even if domain trees were found, I am not sure they belong hard-wired in code. Generally one should not hard-wire non-trivial taxonomies/classification-systems into code. This is what databases are for so that one can get different views of the same data depending on use and context. (Note that many OO proponents use organizational techniques other than hierarchies. However, loss of hierarchies takes with it promises of something simpler than a big messy graph.)

• PolyMorphism - Sub-type polymorphism suffers many of the same problems as inheritance: its "taxonomy" is artificial. Sets are seen as more powerful than lists of mutually-exclusive types or type hierarchies. For one, they handle orthogonality (current or future) better than polymorphism. However, the logical extension of sets leads to relational more or less. OO seems to introduce DiscontinuitySpikes (more change effort) when something goes from IS-A to HAS-A. (There are other kinds of polymorphism besides sub-type, but sub-typing is the most common.) See PolymorphismLimits.

• Encapsulation
  • Grouping related behavior - There is no single "right" grouping because grouping needs are relative and situational. However, "task" grouping is usually more stable than noun-based grouping. Procedural modules can be used to group related functions. See: [in progress, prior material was deleted]
  • Protection of "innards" - Database triggers, referential integrity, and stored procedures can provide similar protection on a larger scale and in multiple languages. On a smaller scale the innards are no more "naked" in procedural than they are in say SmallTalk programs. See: GateKeeper.
  • CantEncapsulateLinks anyhow. OO does not address managing inter-object links in a consistent and robust way.

• Concurrency Issues - We might distinguish OOP from ActorsModel in that OOP objects, in practice, use synchronous messaging (effectively, procedure calls) - i.e. an external 'thread' can be involved in a 'stack' of OO messages at once. This is good for performance-in-the-small, but is also a major source of concurrency bugs (deadlock, race conditions, reentrancy issues) and scalability issues.

• ReinventingTheDatabaseInApplication - and poorly (slow, buggy, small scale, lack consistency properties and concurrency control of dedicated database systems) becomes a common AntiPattern in many OO projects. Some OOP languages or libraries offer persistence (ImageBasedLanguage, HiberNate, GemStone) which can avoid some hassles, but one still ends up reinventing any ad-hoc query and crud operations (because DatabasesAreMoreThanJustStorage).

• Does Not Model Human Mind - The human mind is delightfully capable of holding many 'views' or 'models' of our perceptions at once - based on the patterns we need to emphasize for whichever problem we are solving. In a sense, an object in human perception is just one way of viewing the world. OO forces us to pick just one 'model' and entrench it in our program. The use of stateful objects and encapsulation both prevent us from effectively supporting multiple 'views' by functional or logical transforms. In a very real sense, objects are often 'intuitive' in a bad way that can easily lead us to error.
  • Besides this, how we view things is primarily a function of how we learn to view things - i.e. the patterns that prove most useful to us are the ones that stick in our brains. Because of this, even though fundamental cognition in humans is relatively consistent across the species (with rare exceptions - just as there are exceptions to the '2 arms, 2 legs, 1 heart' rule), such things as culture and prior work experience can have a significant impact on whether OO objects feel so natural to us that some might make hand-wavy allegations that OO models the human mind, or whether we might vehemently deny it.
    • I'd like links to some evidence that "cognition in humans is relatively consistent across the species" if the environment is filtered out as a factor. I'm not even sure that is legally testable outside of Nazi Germany-like techniques. However, for the sake of this discussion, perhaps the nature-vs-nurture issue should be put aside and merely state that developers, as is, think differently. The cause of the difference is mostly irrelevant to this topic and perhaps a distraction. It's TMI for the topic at hand. -t
    • Basic human thought processes, skill acquirement, recognition and learning and so on are the same across the species based on studies in labs and even under MRI. Most are even common across many animals. Study the subject in your own time if it interests you. Different human developers will think about different things - i.e. approaching a common problem from different perspectives. They may have different skill sets to apply, and use different tools to aide their action. But they do not think differently - not in terms of fundamental cognitive mechanisms.
    • I'd have to question that. There are many ways to model processes and abstractions in one's head. Even notation-wise, sets can be modeled as graphs and vice verse. Music scores can be modeled as d-shaped marks or as time-versus-frequency bars (sometimes called "piano-roll view"). Neither is necessarily or summarily "wrong", just different. There is no good data on whether in-born individual traits will make one gravitate toward one or the other in the absence of environmental influences. Studies of separated-at-birth twins suggests that some of it may be in-born. -t
    • The topic line here is "OO Does Not Model The Human Mind." This claim is very different from "The Human Mind Does Not Model OO." An ability to model an OO process in our heads is a skill. Whether OO models our heads is a question of hard, low-level, cognitive psychology. People do have predispositions for different skills, but that isn't relevant under the topic line.
    • Continued at, and eventually moved to OopAndHumanThoughtProcess.

  • A paradigm to model human thought processes would involve recognizing ad hoc patterns in large bodies of data and taking action - i.e. closer to rules-based programming, or temporal logic programming. OO does much to hinder this. Of course, the question of whether a paradigm that models human thought would be a GoodThing is distinct from the question of whether a given paradigm roughly models human thought.

• Behavioral Tilt is Limiting - Behaviors are difficult to pick apart, analyze, share, compare... difficult to query in rich ways. I've read a paper describing a search engine where one could query a code-base with something like: give me a function for roman numerals that, given the values 1,3,4,6 will return "I", "III", "IV", and "VI" respectively. The search engine would then use 'roman' and 'numerals' as search terms in comments and identifiers and would test discovered functions to see if they fit the criterion. However, this sort of query becomes less feasible to perform as behaviors gain dependencies upon objects, global values, deep libraries, and preconditions. Simple data types are much easier to work with, share (with other languages and processes and tools), query, and reason about... and it seems reasonable, therefore, that we should put as much of an application into plain-old-data as we can make fit... and that we should find ways (idioms, patterns, language designs) that allow us to fit even more of an application into data. OO over-emphasizes behavior - as a first resort, when it should be nearer a last resort.
  • Related: DataCentricThinking, CodeAvoidance, InterfaceFactoring.

• Lack of Modeling Consensus - There is a wide variety of opinions about how to do "OO modeling". Some tilt toward the "physical-model" birth of OO in Simula-67, while others prefer ResponsibilityDrivenDesign, for example. Thus, we have both a physical tilt and a social tilt of opinions. Yet others say that OO is simply a way to organize code and should not be a higher-level modeling statement. See OopGoesHalfWay.

• Lacks Normalization Rules - OO has nothing equivalent to relational NormalForm rules and guidelines to produce consistency and reduce known duplication.

• King Noun is Artificial - OO generally assumes there is one PrimaryNoun per action or operation. This assumption is often artificial. There is no such identifiable force of nature or human interaction. The nouns that participate in any given action are often numerous and changing. It is sometimes said that one should group code by the most stable factors. "Task" or "operation" is more stable than nouns or entities for the most part. One should be able to swap/change the noun(s) without changing the calling code. This is InformationHiding. In the real world, the relationship between nouns and actions is often many-to-many, and OO has generally been problematic with many-to-many relationships. ManyToManyChallenge.
  • Counter view moved to PrimaryNoun.

• Marries you to NounModel - Related to above, procedural tends to divorce (decouple) the code "shape" from the NounModel. If the noun-model changes, the impact tends to be less than it would be in OOP. One may have to change query code, but they don't have to change the formal relationship between procedures and modules. (In procedural the NounModel is mostly in the database, at least in biz apps.)
  • This seems redundant. Refactor these arguments, minimize rants. TimeToMakeItShort.

• No Empirical Evidence for OO - The case for OO is mostly based on ArgumentFromAuthority and "toy" examples that some feel distort the probability of certain change patterns. See OoEmpiricalEvidence.

• OO is Xenophobic - In practice information needs to be shared between many tools and many languages and possibly many paradigms. Data-messaging is generally easier for this than behavior-based messaging, and data-centric approaches tend to rub against OO encapsulation philosophy. OO that force 'values objects' for messages compromise the EverythingIsa object concept. See also "Standardized Attribute Management" below.
  • this seems redundant with the 'behavioral tilt'.

• TextbookOo is Deceiving - The simple structures and concepts in OO training material fall by the wayside in the real world, leaving one with a tangled mess that is nowhere near as simple and clean as the examples. Many managers are easily mislead by such examples. ObjectOrientedDesignIsDifficult

• OO is often hard to teach - Beyond TextbookOo examples, OO is hard to "get right" and/or it is tough to articulate in clear language and with open inspection why OO is (allegedly) better. Attempts to justify OO often have an eastern wispy feel rather than a western reductionalist approach favored by modern science.
  • This is not easily justifiable, and is a hand-wavy claim itself. I suggest we remove it.

  • Counter view: That is because OOP should be taught with design patterns. Imagine teaching procedural programming without teaching the methodologies to attack problems (divide and conquer etc.)
  • Visitor is hardly a simplification technique, and there are no clear guidelines for when to apply which pattern. I find the existing guidelines much vaguer and open-ended than relational normalization techniques. (See DoubleDispatchExample)
  • If the confusion demonstrated on this page is any indication, OO is probably a lot harder to teach than it is to learn. {meaning?}

• Global Abstractions - OO tends to assume or strive toward central global abstractions, which are insufficient to handle a multifaceted, relative, and interweaving world. In contrast, DataCentricThinking tries to make one's view be supplied in an as-needed basis based on situational criteria.

• Lacks standardized collection handling - OO has failed to create consistent collection/relationship handling techniques. How multiple objects interact and relate seems to be left up indidivuals with no consensus forming. Each language or shop reinvents its own libraries and conventions, and these often don't scale beyond the language or RAM without one ending up reinventing a database-like-contraptions from scratch. The "reinvention" of such CollectionOrientedVerbs for each and every class is seen as a violation of OnceAndOnlyOnce by some. It "smells" of a larger repeating concept that is not being extracted/factored out to a central protocol or standardized feature set. See InterfaceFactoring, OoConflictsWithCollectionOrientation.
  • Standardized Attribute Management - I'm not sure if this belongs under collection handling or the "xenophobic" item or both. But a frustration I have with OOP is that one cannot study all the attribute assignments (set/get's) with other tools because they are "locked" into an app-language-specific format. If they were in relational form or XML, one could use a standard off-the-shelf table viewer or XML editor/viewer to edit, study, search, sort, query, report on, etc. the soup of attributes. Instead I have to rely on language-specific tools, if there are any. It's not logical for each app language or IDE to reinvent all those collection-oriented idioms (although the stubborn companies will try). -t

• OO runs too slow - I don't necessarily agree with this or even care that much. But others have made such a claim and so I shall at least document that fact that the claim appears from time to time.
  • Later on you say that persistence should be handled by the RDBMS... I can not imagine anything slower than that for the vast majority of the tasks you want to perform.
  • To some extent I agree, but it is hard to call OO the "paradigm of the future" if you use it only because current chips are not fast enough to handle relational-based abstraction. Higher abstraction usually requires more horse-power. Most bottlenecks I encounter have to do with collection-handling issues, not processes themselves, and DB's tend to do well on larger datasets (if decent indexing, normalization, etc.) Thus, OO may be faster when processing 5 items, but not when processing 5000. The 5 item scenario is usually not the bottleneck anyhow. In short, it scales better.

• Some of the justification given for OO comes from lackluster specific languages or lackluster specific implementations. For example, CeeIsNotThePinnacleOfProcedural.

• Fails DivideAndConquer of data and operations - If you split things into data and behavior, then you can apply the best data tools (RDBMS) to the data and the best behavior tools to the behavior. ComparativeAdvantage. OO tends to intermix them, dragging them both down to the lowest common denominator. For example, data schemas (noun relationships) are pretty compact as database schemas, but not so if dispersed around in application code.

• OO forces one to think too much about "persistence". In database-centric approaches, persistence is an almost automatic by-product of using the database. (However, some databases don't support temporary tables very well.) But in OO you are often forced to think about when and where to "save" stuff to disk, complicating the design. Modern caching techniques allow databases to use RAM or disk automatically without the app developer having to select one or worry about it. OO has yet learned to take advantage of such technology.
  • That's too slow.
  • See speed comment above [EditHint: Perhaps move these con's and replies below to keep the primary list uncluttered]
  • Structured programs still have to talk to DBAMs and somebody has to build the DBAMs. OO doesn't make any of this different. The DB access code inside an object method looks just like the corresponding code in a subroutine.
  • OO being (allegedly) good at building an internal DBMS engine does not necessarily mean it is good at every other domain. (See OopNotForDomainModeling.)

• Heavy integration of data and behavior reduce cross-language sharing of protocols and data. (CrossToolTypeAndObjectSharing)

• Since most businesses store attributes in RDBMS, there is often a "paradigm conversion tax" between OO and the RDBMS in terms of complexity and speed.

• OO does not offer any kind of CollectionOrientedProgramming short-cuts. For example, it usually takes a lot of code to iterate through or get summary information about each subclass of a master class. Some feel these kinds of things should be built into something that claims to be a "modern paradigm" or language. But encapsulation seems to disallow it from OO. See near bottom of RelationalBreaksEncapsulation. [Perhaps merge this item with "Lacks standardized collection handling"]

• OOP is for some reason a very productive "fad factory". It generates all kinds of buzzwords and ill-defined concepts that everybody is encouraged to use, but the why's, when's, and how's are not very well defined. This includes patterns, SOA, responsibility-driven design, MVC, etc.

• OO is not suitable for writing application code. OO tends to focus on reuse, stability of the conceptual model and minimization of dependencies. These aspects are not very useful for application code. There are good reasons to use OO for writing reusable platforms or libraries. However, OO has been sold and advertised for all kinds of purposes, usually far exceeding the real scope where it can be applied. Perhaps this can be extended in WhenToUseWhatParadigm.

• OO is Anti-Declarative - OO tends to view things as behavioral wrappers around state. This is against the idea of attribute-driven programming and/or specification. One could create OO frameworks that are mostly assignments to attributes, but this essentially turns it into a database of sorts, but without the query-ability of databases.

• OOP can be too much set-up code for single-spot and single-time usage. Not every piece of code is meant or fit for a generic kit or tool, but is often very domain-specific and task-specific. See ComparingDynamicVariables and YagNi for more.

• See below for a list of ways OOP allegedly violates OnceAndOnlyOnce.

Two themes tend to stand out: artificialness and inconsistency. OO is based on some ideas that are catchy on a small scale or in toy examples, but they don't scale to the real world well, requiring many layers of indirection to work around their limits. Lack of consistency makes it harder to understand and navigate OO designs and study OO in general. Every OO modeler ends up modeling their own head, so you have to learn a new head from scratch each time you encounter a new OO application.

• A proposed remedy for the above points is a UnifiedDataModel to create a true DataEcosystem.
• Oh, there are a lot of different proposed remedies. Perhaps we need a section to list them.

---

Ways in which OO allegedly violates OnceAndOnlyOnce:

• Puts similar-looking behavioral wrappers around attributes, such as accessors.
• Does not factor out similarities in CollectionOrientedVerbs-ish aspects of interfaces (InterfaceFactoring).
• Often echos relationships that are already stored in a database. See CantEncapsulateLinks, MirrorModel.
• Repeats attributes over and over un-necessarily compared to table versions of multiple dispatch, such as the VisitorPattern. See CodeGenerationIsaDesignSmell near PageAnchor "attribute_repeat", and DoubleDispatchExample.

---

Quotes

Quotes and articles about the harmfulness of OO: http://harmful.cat-v.org/software/OO_programming/

A quote from a blog that is not directly about OOP, but makes a reference to it. Source: http://www.joelonsoftware.com/articles/APIWar.html

"A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised."

Nice quote, but as an argument against OOP, it's a classic ArgumentFromAuthority.

• Nothing wrong with that. ArgumentFromAuthority is valid evidence for the real world, but weak evidence.
• Yes there is something wrong with it. It's not evidence at all, even though it's being used as if it was evidence.
• I disagree, but this topic is probably not the best place to discuss that. Tell me that you've never asked a friend for recommendations.
• Of course I've asked friends for advice. However, advice is not evidence, so I don't see how that is relevant.
• It depends on the context and/or community and/or forum. I'd prefer to let the reader decide which kind of evidence they want to keep or ignore rather than a self-elected filterer.
• While it may depend on context, it does not depend on community. While a given community might be willing to treat it as evidence, that community would be committing a fallacy each time it does so. And I am letting the reader decide, I haven't deleted your contributions have I? Keep in mind, that I have just as much right to point out your illogical arguments as you have to make them.
• Yes, it's committing a "fallacy" based on commonly-accepted formal debate rules. But those rules themselves are ArgumentFromAuthority.
• Even if it were just based on commonly accepted debate rules (which it isn't, it's based on the fact that it's an unsound argument), it still wouldn't be an ArgumentFromAuthority since no authority has been invoked.
• So the formal debate rules are not tied to anything? That's not an improvement. And who said this wiki "must" conform to formal debate rules anyhow? Nevermind, I don't want to argue about arguing anymore. That's what wives are for.
  • "It's based on the fact that it's an unsound argument" is "not tied to anything"? And I, too, don't think that wiki needs to conform to formal debate rules. (Do you really want to wait till we have judges before we argue, and have only limited amount of time to form a response?). But even outside of formal debate, a fallacy is still a fallacy.
  • A fallacy is only a "fallacy" against a standard. If you are not clear on the reference standard, it generally comes across as confrontational (although, I suspect you wear that as a badge of honor).
  • {A "fallacy" is any form of argument that is misleading, i.e. where extrapolation leads one to bad conclusions. It doesn't matter whether the conclusion is true or not. I.e. "the sky is blue because Alan Kay says so" is a fallacy, not because the sky isn't blue, but because the argument itself suggests things are true merely because Alan Kay says them. Are you using some other standard for "fallacy"?}
  • "Conversation mode" generally is going to have unstated assumptions, overgeneralizations, and incomplete info. If you shout "fallacy! fallacy!" all the time during that, then you will be lumped with the jesus-shouters on the street corner. This is not court. It's better to ask for clarification or give an example that "breaks" a statement as written.
  • None of those describe the base situation here. You posted a quote, that is someone's opinion, as an argument against OOP. There's nothing to clarify as the quote was perfectly clear. Requiring a counter-proof (which is what "giving an example that 'breaks' the statement" is) is not required, shouldn't be required, and in this case would be quite difficult to obtain. Simply pointing out the flaw in the argument is sufficient. I don't go out of my way to offend people, but if you're offended by having the flaws in your argument pointed out, then I'm afraid you're just going to have to be offended. (By the way, I've stated the reference standard twice now. I really doubt I could make it any clearer by repeating it a third time).
  • Well, I disagree it is an objective "flaw", as already stated. Too many people think things are "objective" when they are not. If you wish to produce a formal proof that it's objectively flawed, please do, but not in this topic.
  • {You tend to call things "subjective" when they are not. That's just you railing against the English language. A fallacy isn't subjectively an invalid form of reasoning: there is no such thing as a form of reasoning that's sound/valid for Top but unsound/invalid for someone else - that is, where validity and soundness depends upon which subject is performing the reasoning. That said, I suspect your goal isn't to argue so much that ArgumentFromAuthority is sound/valid so much as to say that expert opinions have a place in a discussion such as this one - not as arguments, but rather in their capacity as (supposedly) informed opinions. Smoke is circumstantial evidence of fire. Negative opinions about OOP serve, similarly, as evidence that there are some flaws - not necessarily fundamental to OOP, but perhaps common among its popular implementations. Problem is, if this was your intent, you worded it poorly when you said: "ArgumentFromAuthority is valid evidence"; you should have said instead that "ExpertOpinion? (opinions formed in professional capacity by people with experience and information) can serve as strong circumstantial evidence."}
  • I agree I worded it poorly. I'm sorry. -t
  • While I agree that expert opinions have some place, I'm not sure that blog quotes really count as that either. I'd also probably cut you some more slack if you hadn't also argued that references to published technical works didn't count as evidence. (From BookStop, "A BookStop is not accepted in formal debating either. It would be considered ArgumentFromAuthority.")
  • {Those are very reasonable points. And I'd say that blog quotes from an article from an expert that expresses and justifies an opinion would qualify as expert opinion, and I'd even grant that Joel is a reasonably well-informed expert. But the above quote from JoelSpolsky is not from an article focusing upon expressing and justifying an opinion on OOP. It mentions OOP in passing only to suggest OOP has not been as significant to 'productivity' as GarbageCollection.}
    • An expert on what? From what I've been able to determine, his opinions carry the same amount of weight that any senior developers would. I'll listen, and take what he says seriously, but I'll do my own research to back it up. I certainly won't take something he says as true without some verification. For example, his September 23, 2009 blog entry was very troublesome (I'd say my single biggest time waster is dealing with the code left behind by "Duct-tape programmers". Yes, sometimes you have to do it, but trying to claim it's a good thing?)
  • I don't see how the main topic affects the value of statements made about OOP. True, it makes the link less valuable for the topic, but not the quote itself. But does that itself somehow ding it down below a threshold of some kind?
  • {An "expert opinion" means more than mere "opinion". It's an opinion made in professional capacity, informed by the available facts, and subject to request for justification. Joel's article makes no attempt to justify or explain this quote about OOP. That does, indeed, make the quote itself far less valuable. Pulling a quote out of context isn't a praiseworthy act, either.}
  • I disagree with both of these assertions. About the context, the quote is not misleading by virtual of it being isolated. Thus, I see no sin.
  • {I see. TopMind thinks that off-hand comments carry the same weight as expert opinions, and that quoting people out of context is neither misleading nor a sin. Mind if I quote you on that in ObjectiveEvidenceAgainstTopDiscussion?}
  • The paraphrasing is inaccurate, or at least misleading. Anyhow, I ran out of patience to argue about arguing here, and will thus let it sit for now. -t
  • EditHint: Spin this section off into a topic related to ArgumentFromAuthority.
  • The first half seems accurate enough. When it suits your purposes, you'll promote using the off-hand comments while also trying to dismiss published studies. The second half seems a bit unfair. Neither quote on this page lost it's meaning when you quoted them. And I can't think of any time where you clearly misquoted someone.
  • What published studies with source code showing OOP better?
  • Who said anything about "published studies with source code showing OOP better"? I would be rather surprised if such a thing existed because in order to show something "better" in a study, one usually has to cover a much wider variety of code than one could reasonably include (as in actually put in the paper) in the study. But this just reinforces my point. You are already attempting to dismiss published studies by placing unreasonable requirements for acceptance.
  • Could somebody please clarify the statement "while also trying to dismiss published studies". And please stop deleting this question until it is fully answered. Thank You. -t
  • I deleted the line the led from "existing published studies", since that line was a result of a mistake. And, I meant that you have argued that certain forms of evidence (which include published studies), shouldn't be used. The quote I included earlier is one instance. The SelfStandingEvidence page is another.
  • I don't see such. Please use PageAnchors to reference such studies. If I try to guess what you are referring to, it'll probably lead to yet another fat argument about nothing.
  • I'm not talking about any particular study, so there wouldn't be anything to put in a PageAnchor. As for not seeing it, the very opening of SelfStandingEvidence ("Self-standing evidence is the opposite of ArgumentFromAuthority. Such evidence is self-contained and does not require or assume other sources except maybe a basic domain dictionary.") would (if accepted) preclude references to published studies, as the study is an "other source" orther than a "basic domain dictionary".
  • How it relates to this topic, I have no idea. Not sure I want to anymore. I never outright dismissed "published studies" either, for that matter. -t

• {Why do you infer that "formal debate rules are not tied to 'anything'" from "formal debate rules are not tied to 'authority'"? That seems rather daft and illogical to me. And maybe you're right: this wiki shouldn't conform to debate rules; instead, we should give wiki-space and consideration to all opinions, without any rules to point at to claim some opinions unreasonable or unprofessional and thus deserving of dismissal and deletion. On that note: OOP and procedural are both bad because they haven't been touched by the FlyingSpaghettiMonster's noodly appendage. SpaghettiCode, on the other hand, is good because it's very noodly. This must surely be given some weight in ArgumentsAgainstOop, right?}
• Again, I'll let the reader decide how they weigh the elements.
• [Why does OOP inspire such fervour in you?]
• May I ask if this relates to the immediate topic above, or is this a "new" question?
• [This is a "new" question. On a case-by-case basis, I can certainly appreciate choosing an alternative to OOP based on some mathematical, logical, or business rationale or the result of a cost-benefit analysis. However, on a number of Wiki pages you appear to react to it on an emotional level. Why is this? Perhaps a new page would be appropriate to discuss this, such as WhyOopMakesTopMad?, or some such?]
• Debunking OOP hype is a hobby of mine. The hype mucked up some of my favorite tools and trends, so I set out to make the hypsters more accountable for their claims. -t
• [Ok, but why react emotionally? Why not simply illustrate how your favourite tools and trends are/were superior (or at least equivalent) using some well-defined metrics?]
• Where did I act overly emotional? And, I feel that software engineering is mostly about psychology, not universal principles of nature outside of humans (as individuals and as a group). Thus, objective metrics of the kind we find in other fields generally don't exist. See DisciplineEnvy and PsychologyMatters for more. OOP proponents often make statements that imply objectivity, such as "OOP increases modularity". But they cannot deliver the evidence in an objective way. If they said, "it personally helps my mental modularity (MentalIndexability)", then I don't have an argument. It's the implied extrapolation to all beings that makes me sit up.
• {Your "feelings" about psychology are "overly emotional" already. You have faith that PsychologyMatters, but you don't believe any objective evidence is required to make this view a reasonable or convincing one. Your belief system is anti-science, anti-reasoning, anti-intellectual... you might as well start a religion. Without any objective assertions, you can't disprove PsychologyMatters any more than you could disprove ReligionMatters? in software engineering. OOP proponents, at least, use logic to demonstrate certain forms of runtime-ConfigurableModularity that do not exist without the relevant OOP techniques (fundamentally: binding behavior to references polymorphically). You seem to ignore evidence that doesn't come with 'numbers', but that's because you blindly ignore that formal proof is at the very top of the EvidenceTotemPole. Of course, OOP techniques - binding behavior to references - can be implemented in any TuringComplete system (and even many not-TuringComplete systems), rather than just OOPLs. Appealing to that doesn't change the relevant facts; it only says that you can do OOP without a dedicated syntax via a framework and SelfDiscipline. Anyhow, if you're going to say something "personally helps my MentalIndexability", then you should be able to prove it in a psychology lab - i.e. performing recall and recognition and access time tests. And if you're going to claim some psychology benefit is "nature" (as opposed to "nurture"), then you had damn well better be able to provide convincing evidence for it - which means controlling for education and experience.}
• I am not "anti-science". I am just realistic about where (traditional) science can't work (TooManyVariablesForScience).
• {You hold views based on faith. If you were "just realistic", then you would not say that PsychologyMatters. You'd make no assertions based on faith! Being "just realistic" also means skepticism about where psychology would 'matter'. Instead you'd "just" say that you are skeptical of the virtue of science in SoftwareEngineering decisions. You might also say: "As a realist, I can't argue that PsychologyMatters... but, as a human, I do favor some aesthetic elements of programs." By calling yourself a realist alongside your professed beliefs, you're speaking obvious untruths to the world, and I suspect you're lying most of all to yourself.}
• And you've opened too many cans of worms to address in a single paragraph. I suggest we find a more appropriate topic for each rather than create another ThreadMess here. If you have some objective evidence for OOP, perhaps it deserves its own topic. And if we design software based on only what we can scientifically measure, then we risk SovietShoeFactoryPrinciple. Our economy does not depend on micromanaging decision calculations, so why should complex software? -t
• {More fallacies, TopMind? This time: FalseDichotomy and FalseAnalogy.}
  • Yes yes, I always say bad and wrong stuff because I am bad and wrong and purposely set out to be bad and wrong. Antagonistic Jerk!
  • {I consider sophistry a banning-worthy offense. It is very offensive. I consider barging into a conversation and inflicting your ignorance upon the audience to be less offensive, but hardly endearing. So: it doesn't matter whether you do it on purpose; either way, you earn chastisement.}
  • I have similar views about you, but don't believe that insults "fix" people unless done right (which I doubt you have the people skills to do, being the Asberger type). If I insult, its purely to relieve my stress, not to fix. (And "sophistry" is yet another one of those vague insult words you like so much.)
• {(A) Designing software based on what we can deduce and measure doesn't mean designing software based only on what we can deduce and measure (FalseDichotomy). (B) Our economy is not a piece of technology, and we have very little opportunity to 'design' it - the economy is very subject to political pressures outside of any potential designer's control (FalseAnalogy).}
• And software is not subject to political pressure outside of designer's control? As a software designer, a very large part is usually outside of my control unless it's say a personal open source project. I won't claim my statement 100% fallacy-free, but that is not one of them. Also note that an imperfect analogy is not the same as a useless analogy. Don't force Boolean onto non-Boolean concepts.
• {That depends on the size of the 'software' unit and whether you consider requirements to be part of the software or not. But it remains that technology implementation is in the hands of a few designers - an individual architect or a small group - and nothing similar can be said of the economy.}
• As software designers, we have to weigh boat-loads of factors, some which we have full control over, some we have some control over, and some we have no control over. These must all be weighed and acted upon. Software is a system, and the economy is a system. Whether we call it "technology" or not is mostly a name-game. Software can be ran entirely manually if one has the patience. The computer is not necessary.
• {Sure, there are many factors, some of which are more controllable (easy to predict and adjust) than others. That's a common property for "engineering". SoftwareEngineering, in that sense, is far more similar to bridge and architectural engineering than it is to the economy. There are very few factors of the economy that individuals have even 'some' control over.}
• I dissagree with the bridge analogy. Physics is the primary force bridge engineers are up against and it generally doesn't change; but psychology is the primary force that SE's are up against (machine performance being the 2nd.) There's already a long topic on that and I'll link to it when found. -t
• {I think your disagreement flawed. First, you fell back on faith that PsychologyMatters, despite it being in dispute, without any evidence whatsoever - that's what we call HandWaving. Second, aesthetics matter to bridge and architecture design, too. Third, the primary forces that SE's are up against are typically the same forces that bridge designers are up against: limited time, limited budget, requirements to interface/integrate with the outside world, and a wide number of implementation strategies to decide between.}
• The default is not that psychology doesn't matter. Most rational people will agree that the open issue is "how much". As far as the bridge analogy, I'll withhold commenting until I find the related topic.

(Moved further discussion to LinusTorvaldsOnVisualBasic)

---

Binding Behavior to References (BBR)

[sub-topic being refactored]

Of course, OOP techniques - binding behavior to references - can be implemented in any TuringComplete system (and even many not-TuringComplete systems), rather than just OOPLs. Appealing to that doesn't change the relevant facts; it only says that you can do OOP without a dedicated syntax via a framework and SelfDiscipline.

And binding behavior to references existed long before OOP. If anything, later languages *limited* the binding to supply "discipline" above machine/assembler address pointer spaghetti.

What? Do you mean before it was called OOP? Because many people would argue that early use of OOP techniques began with binding behavior to references. And what any 'language' or 'syntax' does is provide some discipline to remove need for SelfDiscipline. But 'BBR' was listed as a 'technique' and not a definition of OOP; the above should have read "OOP techniques - such as binding behavior to references - [...]". OOP means having references to program elements (NygaardClassification), having behavior (including access to state) associated (polymorphically) with these references (rather than injected by the holder of the reference), and the ability to communicate references.

We both seem to agree that OOP at least attempted to introduce discipline to BBR. But this would imply that BBR is not by itself "OOP". OOP is an approach to trying to tame BBR. The "problem" is managing them through navigational paths (OO) rather than relational and/or sets, not the mere existence. In other words, I don't like the way OOP manages the references, but am not bothered by existence of them by itself (if used appropriately). -t

Agreed. Related: the 'no composer' argument at the top. The need to "manage" references in OO is painful, and evil. I prefer my OO mixed with a healthy dose of FP + LogicProgramming + DataflowProgramming, along with an object-configuration builder to build large object configurations declaratively (no assignment operations, no managing order-of-operations). OOP has, without a doubt, many problems. That's true for any single paradigm.

(Moved rest of discussion to ScalingOopDiscussion.)

---

See also OopArgumentsDebatesAndDiscussion, OoLacksConsistencyDiscussion, OopNotForDomainModeling

---

CategoryOopDiscomfort, CategoryObjectOrientation

---

SeptemberZeroNine