The Sourcerer

Overloads and Genericity

I disagree with Professor Bates' general assertion on the ACM Queue that overload is bad based on the specific weaknesses of C++. Bates cites the nightmarish growth of complexity of a C++ program because of a combination of arbitrary complexities. C++ uses a complex scheme of scope resolution and type casting, with multiple ways to invoke type conversions. Because C++ provides so many avenues for these features, there are arbitrary distinctions to determine where one begins and another ends. In a simpler language, as most functional and some procedural languages are, overloading is not a problem because there is only one scope resolution rule and a unified system for defining type conversions. In fact, that these complexities scale exponentially is considered an advantage; being able to understand how your code scales when it interacts with new code is empowering.

Bates argues that "[overloading] adds no significant programming capabilities at all." This overlooks the concept of genericity. Genericity is a concept implemented in static languages like C++ through the use of templates and in dynamic languages like Python inherently. Genericity posits that there are classes that are unrelated in terms of inheritance that subscribe to the same notional behaviors as defined by some set of algebraic identities. So, for all objects that subscribe to the same notion of "addition", a "sum" operator would behave the same way. Or, for all objects that subscribe the notions of symbolic logic, negating any of those objects once gives you an opposite, and negating again renders an equivalent object to the initial. This is a significant programming capability. This permits the implementation of libraries that behave on any object that subscribes to these generic notions.

I do agree that overloading can get out of hand, especially in the hands of programmers that are simply trying to be brief and have no respect for preserving algebraic identities so that their classes can behave predictably. Perhaps future languages simply need a way of explicating these generic relationships. I would be tempted to argue that one can emulate the exact same behaviors with object oriented programing and explicating these relationships with with interfaces, but I doubt this is practical in the long run. Frankly, some people are willing to give up the effort of explicating their intentions on the expectation that other users have taken the same math classes.