I know it's the usual
editor war talk
but since it's not really trolling:
That blog post was moronic..
My point is not to say that this article is "what you should do" but how dangerous/unreadable code the overpowered template engine in C++ can let you write !
If you prefer, I could have pointed to some Boost code like
https://github.com/boostorg/iterator/blob/develop/include/boost/next_prior.hpp to show that some template code isn't IMHO an easy read...
Multiple inheritance is but one form of composition. These things are all tools in a developer’s arsenal. I’ve seen it used to great effect. It’s not the right solution for a lot of things. Neither are delegates. They are very useful in different ways but they are no substitute for being an integrated part of a component.
Actually I'll link to
https://en.wikipedia.org/wiki/Composition_over_inheritance for an example, aka: unless it's for contract (pure virtual) it's, IMHO, bad
(also for Google:
https://google.github.io/styleguide/cppguide.html#Multiple_Inheritance)
Note: this is the enforced model in Java: one class - multiple interfaces... and again, I still consider REAL composition better than inheritance of even a single class.
It’s been 20 years since I wrote any Java. Does Java have delegate support builtin? Or are you just referring to some sort of delegate design pattern that you could do in any language? C# supports multi-cast delegates. The .Net runtime supports both single and multi cast delegates.
I said most languages don't support delegate out of the box.... In case of Java, nothing, but you can (and should) use
Lombok that will generate a lot of "glue" code automatically at compile time based on simple annotation (and magically with the right deps in your build file) without coding/maintaining the pattern.
For Go, they are out-of-the-box, and even better, interfaces don't need to be "inherited" (see
https://gobyexample.com/interfaces)
If some feature in a language bugs you, don’t use it. Most of the clever **** isn’t so clever and it’s rarely the best way to do something in the long run.
I fully agree here... but the problem I see when working in big team, shit WILL hit the fan unless you really have strict reviews rules/{unit,integration,load} testing in place.
And sorry if I flamed a bit on the C++ but telling C++ is better than Java is just not right:
Both used well can give relatively good performances... and both end up more than often misused to unimaginable levels...
And also the reason I like Go - it's refreshingly KISS and designed to avoid programmers trying to do too smart things... but still being extremely powerful... (and yes, it also miss couple of things !)