Inheritance Often Doesn't Make Sense • Hacker News Board

Re: Inheritance Often Doesn't Make Sense

#161

Post by yawaramin » Sat, Mar 17, 2018, 6:59 PM UTC

bitwize wrote: post #137

psyc wrote: post #119

Earlier quoted context omitted.

I get what you're saying, but I'm still persuaded this is what happens with Kay and/or smalltalk. 100 times I've seen threads about OO. 99 times someone brought up Kay/smalltalk. Zero times did they specify why the messaging model was relevant to the present discussion. That's important to do, because more OO programmers use C++/C#/Java, and are not smalltalk experts. So, it seemed to me that they were namedropping.…

Duck typing is central to the Smalltalk "vision thing". That and the idea that a message is a symbolic representation of a method, which an object may or may not support. It is not, in fact, the method, nor does it stand for a direct call to the method. In C++ and Java, for a call to a.foo(12) the compiler can look up the class of a, determine whether it has a foo implementation, and if so compile a call directly wit…

> ... all objects that understand a given protocol (set of methods) and implement it in a sensible way are substitutable with each other (with respect to the protocol) irrespective of their place on the inheritance hierarchy (or even whether such protocol was formally defined)....

This is a very interesting property, and you'll also see it in statically-typed languages which support row polymorphism, like OCaml. OCaml directly supports OOP and subclassing, but it also supports structural typing, which means that objects are type-compatible if they support the same methods.

Unlike Smalltalk, this is all resolved at compile time, so it's quite efficient.

Re: Inheritance Often Doesn't Make Sense

#162

Post by raymondh » Sat, Mar 17, 2018, 7:06 PM UTC

scarygliders wrote: post #73

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much m…

> In a few particular cases, I've found myself having > to move functions out from one subclass and into the > superclass, in order for related subclasses which > needed access to it, for me to be able to add more > functionality to the site.

That seems like a refactoring basic. Far from being miserable, it is likely the easiest way to have met the requirement to add functionality.

Re: Inheritance Often Doesn't Make Sense

#163

Post by true_religion » Sat, Mar 17, 2018, 7:06 PM UTC

psyc wrote: post #119

PaulStatezny wrote: post #114

Earlier quoted context omitted.

I really dislike this kind of hand-wavy dismissal of ideas/opinions as “programmer-hipster”. It seems to assume the person in question has no intelligent reason behind their thoughts/opinions. And it dismisses the opinion instead of engaging with it intellectually. And having been on the receiving end, it’s insulting. It feels like being called stupid. It’s fine to disagree with opinions, but when you assume people a…

I get what you're saying, but I'm still persuaded this is what happens with Kay and/or smalltalk. 100 times I've seen threads about OO. 99 times someone brought up Kay/smalltalk. Zero times did they specify why the messaging model was relevant to the present discussion. That's important to do, because more OO programmers use C++/C#/Java, and are not smalltalk experts. So, it seemed to me that they were namedropping.…

The concept of smalltalk are implemented to some degree in many dynamic languages like Ruby, Python, Perl, Elixir, etc.

And if we are going to talk about functional programming, we can't exclude languages like Python for having too small a user base, as their popularity and impact is often wider than that of any static functional language.

Re: Inheritance Often Doesn't Make Sense

#164

Post by dc443 » Sat, Mar 17, 2018, 7:23 PM UTC

coldtea wrote: post #110

tome wrote: post #43

Earlier quoted context omitted.

Is the real world "subtypeable", in your opinion?

Sure. I want a vehicle to go to work. A car, preferably, but a motorcycle or bus will do too in a pinch.

I don't know about this. Is a teleporter a vehicle? What about a vehicle which doesnt have wheels, in a world built around assuming that vehicles have wheels?

Re: Inheritance Often Doesn't Make Sense

#165

Post by dyarosla » Sat, Mar 17, 2018, 7:34 PM UTC

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…

You’ve described interfaces, not so much inheritance.

Re: Inheritance Often Doesn't Make Sense

#166

Post by eikenberry » Sat, Mar 17, 2018, 7:37 PM UTC

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…

What you are describing is an interface, not inheritance. They are implementing an pulley interface, not inheriting a specific pulley implementation from a common housing or something.

Re: Inheritance Often Doesn't Make Sense

#167

Post by nradov » Sat, Mar 17, 2018, 7:40 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…

Perhaps that works in theory, but in practice abstract domain modelling only gets you so far. In the real world to build a working system that solves a real problem you typically have to work iteratively from both ends simultaneously until you eventually meet in the middle. Do some modelling, then write some code to validate your understanding and understand what's really going to work, then repeat ad nauseum.

Re: Inheritance Often Doesn't Make Sense

#168

Post by eikenberry » Sat, Mar 17, 2018, 7:40 PM UTC

IMO this is one of the primary reasons many modern languages not not strictly Object Oriented. They usually support objects to a limited extent, but a certainly not OO like the 90s languages.

Re: Inheritance Often Doesn't Make Sense

#169

Post by bitwize » Sat, Mar 17, 2018, 7:42 PM UTC

BeeOnRope wrote: post #159

bitwize wrote: post #137

Earlier quoted context omitted.

Duck typing is central to the Smalltalk "vision thing". That and the idea that a message is a symbolic representation of a method, which an object may or may not support. It is not, in fact, the method, nor does it stand for a direct call to the method. In C++ and Java, for a call to a.foo(12) the compiler can look up the class of a, determine whether it has a foo implementation, and if so compile a call directly wit…

> 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 program, and it can be debugged on the spot without recompiling much more than a single method.

Re: Inheritance Often Doesn't Make Sense

#170

Post by divs1210 » Sat, Mar 17, 2018, 7:43 PM UTC

GuiA wrote: post #153

divs1210 wrote: post #125

Earlier quoted context omitted.

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. . .

I’m confused about your analogy. Indo-Arabic number representation enables one to mentally carry out computations that would be much more complex in Roman notation. The notation might not be the solution, but the notation certainly enables solutions not really conceivable in other notations.

I believe functions + immutable data enable me to mentally figure out solutions to complex problems that would be much more complex if solved with objects and inheritence and mutable state.