Recently I found about two new programming languages(Vala and google’s GO) which don’t support method or function overloading and intend on not supporting them in the future ever! The creators of these languages say that overloading is evil and should not be used!(in system programming?)
I was told that the creators of Go Language even say that classes inheritance are evil as well and Go doesn’t support that!
My question is:
Are they really that bad that the new languages are omitting them? Or Is there a specific field of usage for that languages which makes them evil? What could be the disadvantage of using such facilities at all?
5
I can see where they’re coming from, but as rules I would say these are way too specific for 100% restriction in a language design.
Gigantic 18+ layer convoluted inheritance schemes are pretty well-established as an anti-pattern for instance but inheriting 1-3 levels deep can be perfectly reasonable for solving certain problems depending on what other things a language design allows.
Likewise, it’s fairly easy to see how method overloading could be done to excess, making an API so overwrought that you’d have to check the docs every time just to figure out how to use a method for the one of 16 ways you actually need it to work. Whereas, used responsibly, it’s fairly easy to see how overloading for similar types in the same pattern could be completely reasonable and not at all difficult to remember. That, even more so than the inheritance thing strikes me as an odd feature to restrict wholesale. But, full-disclosure: I’m comfortable with a paradigm where everything is mutable, you don’t have to declare a method twice to overload its arguments, and first class functions rain down from all over the place like candy from a busted-open pinata.
That said, just because I don’t like it, doesn’t mean languages can’t make a good case for being highly restrictive. Java for instance (as I understand it) is essentially a design response to the issue of C/C++ code tending to allow so much granular control that it can be very hard for two devs to understand each other’s code. Java’s inherent conservatism/protectionism allows a lot more developers to work together on the same project while having less trouble understanding what the other devs are on about because, for instance, everything absolutely must be in a class. And you don’t get things like pointers which are certainly powerful but can also very easily turn a code-base into a waking nightmare in mediocre hands. I might argue that most of the time having a lot of developers in the first place is its own problem but I wouldn’t go so far as to say this is never a necessity or that they’d always be better off with the dynamic flexibility of JavaScript or the full-on close-to-chrome granular control of C++.
I would however argue that a general purpose language should probably be more flexible than Java is but that’s not something 75% of Stack is likely to agree with me on necessarily.
Languages are inherently about design trade-offs. What this really comes down to is how sold you are on the philosophy in terms of solving the problems you typically need to solve. In this case, I think they’re being silly for the vast majority of problems I’ve personally needed to solve but most of that is web UI stuff.
3
Classes, method overloading, operator overloading… they are all tools. They are suitable in some circumstances, not in others. Don’t try to apply labels like “evil” to such things; instead, strive to understand them so you can decide for yourself whether they are useful or not.
2
The premise of your question is flawed: GOO supports both overloading and classes.
1