4 ms·

Another quote: ------------------ The No True Scotsman fallacy leads to arguments like this: Person A: “No Scotsman ever steals.” Person B: “I know of a Sco

Another quote: ------------------ The No True Scotsman fallacy leads to arguments like this: Person A: “No Scotsman ever steals.” Person B: “I know of a Scotsman who stole.” Person A: “No True Scotsman would ever steal.” Person A is thus protected from the harmful effects of new information. New information is dangerous, as it might cause someone to change their mind. New information can be rendered safe simply by declaring it to be invalid. Person A believes all Scotsman are brave and honorable, and you can not convince them otherwise, for any counter-example you bring up is of some degraded Untrue Scotsman, which has no bearing on whatever they think of True Scotsman. And this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I complain that Scala involves too much ceremony, I’m told that Ruby lacks ceremony. If I complain about the dangers of monkey-patching in Ruby, I’m told that True OOP Programmers know how to use the meta-programming to their advantage, and if I can’t do it then I am simply incompetent. I should use a language that is more pure, or a language that is more practical, I should use a language that has compile-time static data-type checking, or I should use a language that gives me the freedom of dynamic typing. If I complain about bugginess, I’m told that those specific bugs have been fixed in the new version, why haven’t I upgraded, or I’m told there is a common workaround, and I’m an idiot if I didn’t know about it. If I complain that the most popular framework is bloated, I’m told that no one uses that framework any more. No True OOP Programmer ever does whatever it is that I’m complaining about. http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr...

gedy 9y ago
Valid points, but I suppose that's an issue with anything, have heard similar from functional programming advocates, etc
meheleventyone 9y ago
I don’t think those are No True Scotsman fallacies. Or at least not as you describe them. The problem appears to stem from using specific languages to argue about a broader concept. Java being verbose, Scala having too much ceremony and Ruby allowing monkey patching aren’t really complaints about OOP per se. Nor are issues of static or dynamic typing, bugs or bloat. For example the discussion here hasn’t seen a lot of shying away from the practical and conceptual issues with inheritance.
jacques_chester 9y ago
The No True Scotsman fallacy is based on the arguments of a single interlocutor who is trying to evade the conclusion. Your description sounds more like a series of different conversations with different people at different times starting from different topics. Since people, times and topics vary, yeah, you'll get different counterarguments. Especially since, like all programming theories, the content, meaning and boundaries of OOP are widely disagreed on. But that doesn't make it a No True Scotsman.
LifeLiverTransp 9y ago
I think OO has so many fierce defenders, due to the simplicity of the concept, allowing even the mediocre to paint a system by the photograph of reality as it is imagined to be. In this Object Orientated Fairy world even the Programmer has a place- he usually becomes the "Controller" Object - passing messages and half finnished objects between components. Everyone can do this, everyone can relatively fast read into this. And this is why object orientation persists. It has no value beyond that. Inheritance is one of those concepts, people went overboard with in the 90s, generating matroschka objects- that only the compiler could read and whos methods without a IDE where unguessable. Since then- we put it into the history box, and replaced it with composition, which is inheritance in all but syntax and creation call hierarchy. The attack on the holy mountain of OO is thus doomed to be unsuccesfull, because those who are besieged up there can not come down here- because they allready struggle with "normal" code and are happy to code down reality as seen by some "architect". Efficiency or adequate abstraction, is not actually part of the discussion. Neither is speed. What it provides is accessability- and that it provides rather well. Its a crutch for human minds- and a good one at that.
jknoepfler 9y ago
What are you trying to argue? Like what's the actual proposition that you're putting forward? Those mostly sound like scattered, particular complaints about particular OO languages, none of which have anything to do with OOP as a paradigm (as far as I can tell). If you're trying to suggest that there is no viable OOP programming language, that's manifestly false, as trillions of dollars of value have been created following the OOP paradigm in various OOP-oriented languages. If you're trying to argue that there is no perfect OO language, I'd agree with you but argue that the it's a trivial consequence of there being no perfect programming language in general (language design is a game of trade-offs). If you're trying to suggest that every use of OOP could be replaced by a clearly superior, readily available, battle-tested non-OOP approach (which you haven't, you've just listed languages and language flaws with no alternatives), the argument sounds pretty implausible. You can weaken some of these claims to make some headway (replace always with in general or whatever), but that kind of takes the wind of out the argument's proverbial sails. Personally I dislike OO approaches because I usually work on greenfield projects, and every example of OO in a greenfield context that I've seen has been deeply premature and slowed down development. (I also think the DRY principle is a pile of crap in a greenfield context with highish-level code). When I pull down a gigantic, mature Apache repo though, I'm usually not put off by mature OO abstractions, and they (in general) help me follow and add to the code. It cuts both ways. Like most ideas cooked up by smart people solving hard problems, OO is imperfect but sometimes useful.

gedy 9y ago

Valid points, but I suppose that's an issue with anything, have heard similar from functional programming advocates, etc

meheleventyone 9y ago

I don’t think those are No True Scotsman fallacies. Or at least not as you describe them. The problem appears to stem from using specific languages to argue about a broader concept. Java being verbose, Scala having too much ceremony and Ruby allowing monkey patching aren’t really complaints about OOP per se. Nor are issues of static or dynamic typing, bugs or bloat. For example the discussion here hasn’t seen a lot of shying away from the practical and conceptual issues with inheritance.

jacques_chester 9y ago

The No True Scotsman fallacy is based on the arguments of a single interlocutor who is trying to evade the conclusion. Your description sounds more like a series of different conversations with different people at different times starting from different topics. Since people, times and topics vary, yeah, you'll get different counterarguments. Especially since, like all programming theories, the content, meaning and boundaries of OOP are widely disagreed on. But that doesn't make it a No True Scotsman.

LifeLiverTransp 9y ago

I think OO has so many fierce defenders, due to the simplicity of the concept, allowing even the mediocre to paint a system by the photograph of reality as it is imagined to be. In this Object Orientated Fairy world even the Programmer has a place- he usually becomes the "Controller" Object - passing messages and half finnished objects between components. Everyone can do this, everyone can relatively fast read into this. And this is why object orientation persists. It has no value beyond that. Inheritance is one of those concepts, people went overboard with in the 90s, generating matroschka objects- that only the compiler could read and whos methods without a IDE where unguessable. Since then- we put it into the history box, and replaced it with composition, which is inheritance in all but syntax and creation call hierarchy. The attack on the holy mountain of OO is thus doomed to be unsuccesfull, because those who are besieged up there can not come down here- because they allready struggle with "normal" code and are happy to code down reality as seen by some "architect". Efficiency or adequate abstraction, is not actually part of the discussion. Neither is speed. What it provides is accessability- and that it provides rather well. Its a crutch for human minds- and a good one at that.

jknoepfler 9y ago

What are you trying to argue? Like what's the actual proposition that you're putting forward? Those mostly sound like scattered, particular complaints about particular OO languages, none of which have anything to do with OOP as a paradigm (as far as I can tell). If you're trying to suggest that there is no viable OOP programming language, that's manifestly false, as trillions of dollars of value have been created following the OOP paradigm in various OOP-oriented languages. If you're trying to argue that there is no perfect OO language, I'd agree with you but argue that the it's a trivial consequence of there being no perfect programming language in general (language design is a game of trade-offs). If you're trying to suggest that every use of OOP could be replaced by a clearly superior, readily available, battle-tested non-OOP approach (which you haven't, you've just listed languages and language flaws with no alternatives), the argument sounds pretty implausible. You can weaken some of these claims to make some headway (replace always with in general or whatever), but that kind of takes the wind of out the argument's proverbial sails. Personally I dislike OO approaches because I usually work on greenfield projects, and every example of OO in a greenfield context that I've seen has been deeply premature and slowed down development. (I also think the DRY principle is a pile of crap in a greenfield context with highish-level code). When I pull down a gigantic, mature Apache repo though, I'm usually not put off by mature OO abstractions, and they (in general) help me follow and add to the code. It cuts both ways. Like most ideas cooked up by smart people solving hard problems, OO is imperfect but sometimes useful.