4 ms·

I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have

I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here? And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers. If you are doing Python or JavaScript, you often don't have much of a clue what the type of "foo" is in that "foo.save(a, b);" call, and so you don't know which of the "save" methods are being called. And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)

The_Colonel 6y ago
> I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here? Deep inheritance trees came out of fashion (everywhere, not just in Java) long time ago. Inexperienced developers can misuse inheritance in Python just like in Java. > And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers. As opposed to Python or JS where "we don't know for sure so it's gonna be safer to not refactor". > And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-) That's an extremely optimistic view.
- nicoburns 6y ago
  > That's an extremely optimistic view. I haven't seen inheritance more than one level deep in JavaScript for years. And most code isn't using it at all.
  - The_Colonel 6y ago
    Inheritance in JS is not widely used since even the concept of classes is still very new and technically not safe for use (not supported in IE), not because JS devs are somehow wiser and self-limiting themselves to one level inheritance. (unless you mean prototype based inheritance which is very different beast)
    - nicoburns 6y ago
      > unless you mean prototype based inheritance which is very different beast All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. In theory you can do all sorts of crazy things with prototypes. In practice people use them just like classes. The reason people don't use inheritance in JS has nothing to do with browser support.
      - The_Colonel 6y ago
        > All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. And async/await is promise based yet it results in quite different programming style. It doesn't matter which primitives are used for feature implementation. > The reason people don't use inheritance in JS has nothing to do with browser support. I don't think so. Since the advent of ES6/Babel/TypeScript I see inheritance on frontend daily.

The_Colonel 6y ago

> I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here? Deep inheritance trees came out of fashion (everywhere, not just in Java) long time ago. Inexperienced developers can misuse inheritance in Python just like in Java. > And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers. As opposed to Python or JS where "we don't know for sure so it's gonna be safer to not refactor". > And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-) That's an extremely optimistic view.

nicoburns 6y ago
> That's an extremely optimistic view. I haven't seen inheritance more than one level deep in JavaScript for years. And most code isn't using it at all.
- The_Colonel 6y ago
  Inheritance in JS is not widely used since even the concept of classes is still very new and technically not safe for use (not supported in IE), not because JS devs are somehow wiser and self-limiting themselves to one level inheritance. (unless you mean prototype based inheritance which is very different beast)
  - nicoburns 6y ago
    > unless you mean prototype based inheritance which is very different beast All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. In theory you can do all sorts of crazy things with prototypes. In practice people use them just like classes. The reason people don't use inheritance in JS has nothing to do with browser support.
    - The_Colonel 6y ago
      > All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. And async/await is promise based yet it results in quite different programming style. It doesn't matter which primitives are used for feature implementation. > The reason people don't use inheritance in JS has nothing to do with browser support. I don't think so. Since the advent of ES6/Babel/TypeScript I see inheritance on frontend daily.