6 ms·

Re: using composition In the past, it was feared that this would lead to reduced performance but this is simply not the case. Great to see the strong

Re: using composition In the past, it was feared that this would lead to reduced performance but this is simply not the case. Great to see the strong evidence here /s

burnished 5y ago
It might be more productive if you were to outright disagree with the statement instead of simply noting a claim that isn't strongly substantiated. If you have experiences that demonstrate to you that this claim is weak I'm sure everyone else would be interested in them (I know I would be!).
- vlovich123 5y ago
  To add onto that, I tried several different hand rolled alternatives to a c++ vtable and the builtin functionality outperformed them all which was surprising. It’s entirely possible I didn’t know what I was doing but I think my point is that vtables are a language feature that compilers know how to reason about and apply optimizations to. Other concepts not so much.
  - tux3 5y ago
    Something to keep in mind when microbenchmarking virtual calls is that compilers will happily devirtualize them whenever possible.
    - vlovich123 5y ago
      Yeah I’m aware but I made sure the same devirtualization would apply in production too so the compiler doing any devirtualization was good. It was a bit surprising that vtables outperformed std::variant (and I had tried implementing my own hand rolled equivalent of that too).
- pid-1 5y ago
  "what may be asserted without evidence, may be dismissed without evidence"
  - burnished 5y ago
    Where is your evidence for that claim? Seems like I should dismiss it out of hand.
    - rzzzt 5y ago
      QED.
Supermancho 5y ago
Language Design: Let's start with the admission that there's a lot of cargo culting in language design. Evidence is hard to come by and the best evidence is other languages that succeed with different choices. I remember the flame wars about how multiple inheritance would cause a language to fall apart. When will languages adopt the idea that encapsulation is not sacrosant, as the theoretical issue about the backdooring like _method in python or package level public in Go^ is, someone might abuse it? Howabout make testing a first class concept and lump it in there or just use the shortcuts that have been working. What is inheritance? Inheritance (for any given language) is a language supported type of class composition (https://youtu.be/eEBOvqMfPoI?t=2874 https://youtu.be/eEBOvqMfPoI?t=2874), as a closure. A class is a function and once you understand this, it opens up possibilities in how you design and test. This has nothing to do with performance, which is a nonsequitor. Is Rust less performant than Java because of how it does composition? No. Perhaps there's something in the JVM that makes mixins difficult to optimize for, but that would require some evidence (there's no general branch prediction in the JVM, last I checked) and is, ultimately, at the feet of the JVM implementation. Have a look at Go and Rust. Naturally, because a specific kind of inheritance is a language feature, it gets overused and a language, (like Java) for backward compatibility's sake, overuses it in designing new features. Looking at other languages like Javascript, Lua, Erlang, PHP, Ruby, Rust, etc. saner heads have prevailed and even Java has resorted to using "Aspects" ...which are runtime traits for additional types of composition^^. Regarding the rest of the article... His arguments for using final include: 1. Someone may forget to use super() and that's bad because what I want to happen trumps what they want to happen. 2. People can't subclass my class across package boundaries, because I don't know why handwaved JPMS (then covered in Should Inheritance Across Package Boundaries Ever be Used?). His reasoning is not compelling, in the least. I can say, without hesitation, that 'final' is harmful. Adding final to a class is such a violation of the concept of reusable software, I'm surprised the FSF doesn't boycott languages. In C++ there are performance benefits. In Java it's just to put up a roadblock. This was never a good idea and makes testing impossible in some cases (where final classes are injected into final classes). This is purely because of Java's design as a language, not because of some demonstrably helpful concept, implemented poorly^^. ^If you are a language designer, always allow backdooring of accessors for testing, at the very least. This conviction that they must always apply to protect developers from each other is misplaced and has hurt the reliability of software, badly. ^^Spring has a form tacked-on composition, which is both ugly from a conceptual standpoint and problematic from a testing standpoint. Java always seems 20+ years behind.
stormbrew 5y ago
I mean, I'm not sure where this 'fear' even came from? At its core, inheritence is a special case of composition anyways (looked at from the other perspective it's syntactic sugar over either static or dynamic delegation), so it can't really be "faster". At any rate, there's no abstraction so powerful it can prevent a programmer from making it slow.
- lostmsu 5y ago
  This is true for languages where most objects are not garbage-collected. In Java (modern days) this would add a level of indirection.
  - kaba0 5y ago
    Which may be in certain cases trivially optimizable. Eg. an object available only inside a class can have its method calls inlined into the containing class’s methods. (But I’m no JVM developer (unfortunately) so I’m not sure whether this exact optimization exists or not)

Re: using composition In the past, it was feared that this would lead to reduced performance but this is simply not the case. Great to see the strong evidence here /s

burnished 5y ago

It might be more productive if you were to outright disagree with the statement instead of simply noting a claim that isn't strongly substantiated. If you have experiences that demonstrate to you that this claim is weak I'm sure everyone else would be interested in them (I know I would be!).

vlovich123 5y ago
To add onto that, I tried several different hand rolled alternatives to a c++ vtable and the builtin functionality outperformed them all which was surprising. It’s entirely possible I didn’t know what I was doing but I think my point is that vtables are a language feature that compilers know how to reason about and apply optimizations to. Other concepts not so much.
- tux3 5y ago
  Something to keep in mind when microbenchmarking virtual calls is that compilers will happily devirtualize them whenever possible.
  - vlovich123 5y ago
    Yeah I’m aware but I made sure the same devirtualization would apply in production too so the compiler doing any devirtualization was good. It was a bit surprising that vtables outperformed std::variant (and I had tried implementing my own hand rolled equivalent of that too).
pid-1 5y ago
"what may be asserted without evidence, may be dismissed without evidence"
- burnished 5y ago
  Where is your evidence for that claim? Seems like I should dismiss it out of hand.
  - rzzzt 5y ago
    QED.

Supermancho 5y ago

Language Design: Let's start with the admission that there's a lot of cargo culting in language design. Evidence is hard to come by and the best evidence is other languages that succeed with different choices. I remember the flame wars about how multiple inheritance would cause a language to fall apart. When will languages adopt the idea that encapsulation is not sacrosant, as the theoretical issue about the backdooring like _method in python or package level public in Go^ is, someone might abuse it? Howabout make testing a first class concept and lump it in there or just use the shortcuts that have been working. What is inheritance? Inheritance (for any given language) is a language supported type of class composition (https://youtu.be/eEBOvqMfPoI?t=2874 https://youtu.be/eEBOvqMfPoI?t=2874), as a closure. A class is a function and once you understand this, it opens up possibilities in how you design and test. This has nothing to do with performance, which is a nonsequitor. Is Rust less performant than Java because of how it does composition? No. Perhaps there's something in the JVM that makes mixins difficult to optimize for, but that would require some evidence (there's no general branch prediction in the JVM, last I checked) and is, ultimately, at the feet of the JVM implementation. Have a look at Go and Rust. Naturally, because a specific kind of inheritance is a language feature, it gets overused and a language, (like Java) for backward compatibility's sake, overuses it in designing new features. Looking at other languages like Javascript, Lua, Erlang, PHP, Ruby, Rust, etc. saner heads have prevailed and even Java has resorted to using "Aspects" ...which are runtime traits for additional types of composition^^. Regarding the rest of the article... His arguments for using final include: 1. Someone may forget to use super() and that's bad because what I want to happen trumps what they want to happen. 2. People can't subclass my class across package boundaries, because I don't know why handwaved JPMS (then covered in Should Inheritance Across Package Boundaries Ever be Used?). His reasoning is not compelling, in the least. I can say, without hesitation, that 'final' is harmful. Adding final to a class is such a violation of the concept of reusable software, I'm surprised the FSF doesn't boycott languages. In C++ there are performance benefits. In Java it's just to put up a roadblock. This was never a good idea and makes testing impossible in some cases (where final classes are injected into final classes). This is purely because of Java's design as a language, not because of some demonstrably helpful concept, implemented poorly^^. ^If you are a language designer, always allow backdooring of accessors for testing, at the very least. This conviction that they must always apply to protect developers from each other is misplaced and has hurt the reliability of software, badly. ^^Spring has a form tacked-on composition, which is both ugly from a conceptual standpoint and problematic from a testing standpoint. Java always seems 20+ years behind.

stormbrew 5y ago

I mean, I'm not sure where this 'fear' even came from? At its core, inheritence is a special case of composition anyways (looked at from the other perspective it's syntactic sugar over either static or dynamic delegation), so it can't really be "faster". At any rate, there's no abstraction so powerful it can prevent a programmer from making it slow.

lostmsu 5y ago
This is true for languages where most objects are not garbage-collected. In Java (modern days) this would add a level of indirection.
- kaba0 5y ago
  Which may be in certain cases trivially optimizable. Eg. an object available only inside a class can have its method calls inlined into the containing class’s methods. (But I’m no JVM developer (unfortunately) so I’m not sure whether this exact optimization exists or not)