Inheritance Often Doesn't Make Sense • Hacker News Board

Re: Inheritance Often Doesn't Make Sense

#181

Post by skj » Sat, Mar 17, 2018, 9:14 PM UTC

divs1210 wrote: post #125

TheOtherHobbes wrote: post #116

Earlier quoted context omitted.

I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer. OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply…

I think the problem is more that Roman and Indo-Arabic numerals teach that the solution is in the notation, when in fact the solution is in the mathematician. . .

The fact that there are some things where this relation does not hold is not an argument against the OPs claims.

Re: Inheritance Often Doesn't Make Sense

#182

Post by jknoepfler » Sat, Mar 17, 2018, 9:27 PM UTC

lkrubner wrote: post #81

contingencies wrote: post #7

The programmer's perspective: The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham. Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998. The problem w…

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 de…

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.

Re: Inheritance Often Doesn't Make Sense

#183

Post by taurath » Sat, Mar 17, 2018, 9:28 PM UTC

smt88 wrote: post #122

TheOtherHobbes wrote: post #116

Earlier quoted context omitted.

I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer. OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply…

Neither OOP nor FP can fix a bad programmer. I agree. Static typing is similar. But, like static typing, the right environment can prevent whole classes of bugs and maintenance issues. It's just harder to write bad code in FP when your inputs are explicit and there is no implicit state.

The classes of bugs you get in an OOP heavy conceptual modelling inheritance tend to be far more difficult to reason about, because half of the damn classes using it end up being utility classes, so you end up modeling a computer that does a thing instead of the thing.

Re: Inheritance Often Doesn't Make Sense

#184

Post by jcelerier » Sat, Mar 17, 2018, 9:31 PM UTC

bitwize wrote: post #169

BeeOnRope wrote: post #159

Earlier quoted context omitted.

> This is NOT true with C++, absent template metaprogramming... So it is true in C++ then, right? It's only not true in "C++ minus templates" which is a language no one uses.

Introducing template metaprogramming comes with its own passel of problems: compile times (and code size) can explode, and then there are the difficult-to-debug error messages if you screw up. Because Smalltalk uses latent types, these decisions are deferred till run time, which is a loss for static analysis, but doesn't require a separate generated bit of code for every combination of arbitrary types used in the pro…

> Introducing template metaprogramming comes with its own passel of problems: compile times (and code size) can explode, and then there are the difficult-to-debug error messages if you screw up

I don't know any even remotely large recent C++ project that does not use templates at some point. Templates are central to C++ since Alexandrescu's book and the main point around which the current language revolves.

Re: Inheritance Often Doesn't Make Sense

#185

Post by guiscreenshots » Sat, Mar 17, 2018, 9:31 PM UTC

donatj wrote: post #179

DubiousPusher wrote: post #160

If you ever open the hood of a modern car and look around a bit you'll discover that at the front there's a half dozen pullies connected to one or more belts. Each of these pullies is connected to some diffeerent system each able to turn rotational acceleration into a useful service. The alternator converts that rotational energy into electricity. The AC unit uses it to operate a heat pump. The coolant and oil pumps…

Which is also why these modern cars have turned a minor belt failure into an expensive catastrophic failure, often destroying much of the engine. I'd hardly call it a design to aspire to. I'd probably compare it more closely with a system where everything receives a mutable God object.

He's describing the accessory belt. You're referring to the timing belt.

Re: Inheritance Often Doesn't Make Sense

#186

Post by galaxyLogic » Sat, Mar 17, 2018, 9:33 PM UTC

I think there's no Silver Bullet. But there are bullets

Re: Inheritance Often Doesn't Make Sense

#187

Post by galaxyLogic » Sat, Mar 17, 2018, 9:35 PM UTC

contingencies wrote: post #7

The programmer's perspective: The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham. Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998. The problem w…

> The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages. - Alan Kay

In other words it is about avoiding brittle hard-coded dependencies. When you "send a message" you can't depend on the implementation of the responding party. I think that's the general idea.

Re: Inheritance Often Doesn't Make Sense

#188

Post by austincheney » Sat, Mar 17, 2018, 9:46 PM UTC

TheOtherHobbes wrote: post #116

contingencies wrote: post #7

The programmer's perspective: The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham. Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998. The problem w…

I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer. OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply…

> I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer.

I would say the solution is in the appropriate construct. Do whatever means writing the least amount of code possible. Less code means less to maintain and less to execute.

Re: Inheritance Often Doesn't Make Sense

#189

Post by kqr » Sat, Mar 17, 2018, 9:46 PM UTC

skybrian wrote: post #151

kqr wrote: post #136

Earlier quoted context omitted.

I actually don't think the problem is one of mutability/immutability – it's just that a mutable setting very clearly exposes the problem. I think the core of the problem is that the object model has permanently and irreversibly associated an identity to an object based on attributes that are actually malleable. Someone else made a good connection to pastry dough, which can be shaped even more freely. We would never h…

Yes, and that's directly related to immutability. Immutable objects are timeless; their initial state is their final state. Any property that holds for their initial state can be encoded in the type and placed somewhere above it in the inheritance hierarchy. You can think of a mutable object as a collection of immutable and mutable properties, where only the former can be moved into the type and become part of the ty…

Very well put.

Re: Inheritance Often Doesn't Make Sense

#190

Post by [deleted] » Sat, Mar 17, 2018, 10:10 PM UTC

jdmichal wrote: post #175

skywhopper wrote: post #65

Earlier quoted context omitted.

Agreed. In fact I would expect the Square subclass to implement width= and height= so that they each actually set both internal values.

As niklasjansson points out, this solution breaks Liskov substitution. Squares programmed in such a way are no longer substitutable for rectangles. Breaking Liskov substitution is a great way to hide bugs and make your codebase extremely hard to reason about, due to the fact that every subtype can have drastically different behavior than what's defined by the parent type.

[deleted]