I’m 12 years late to the party. Again. Hear me out.

Java Does it Wrong

Java’s design leans heavily on the (correct) belief that the average programmer is imperfect, lazy, and ill-informed. In response, Java acts like a typical overbearing parent. Java knows that you’re too lazy to check whether or not you’re REALLY writing inside of array bounds, so Java does it for you. Programmers are too forgetful to free all memory that they have initialized. Java does it for you. In fact, pointers are hard, so you don’t get to use them in the traditional sense. At all. Maybe when you’re older.

Some very good things came from this policy, like memory management, batteries-included mentality, and Javadoc. Javadoc is a tool that automatically generates pleasant documentation based on your comments, and it’s a freebie. You’re left with no excuse but to actually document your program, unless you refuse out of malice.

However, operator overloading must have really burned the designers at Sun, because overriding operators isn’t in the language. Maybe the designers were offended that C++ overrode the bit-shift operators (<< and >>) for input and output. Maybe they came across a home-grown database system that used every operator under the Sun to perform tasks. Whatever the reason, it’s just not in the language.

Well, almost not in the language. As a convenience, they decided to throw C++’s unwashed masses a bone when it came to Strings. You get the ‘+‘ operator.

String a = "Hello " + "World!";

Do you feel the wind rushing through your hair yet? Me neither.

According to the documentation this is just syntactic sugar, as Java treats this as using StringBuilder or a StringBuffer along with append methods.

Consequences

In the event that you don’t think that the lack of operator overloading is harmful, let’s consider the discriminant in the quadratic formula.

// a, b, c are floats
discriminant = b*b - 4*a*c;

This looks pretty easy, right? Now let’s look at it as a BigDecimal:

// a, b, c are BigDecimals
discriminant = (b.multiply(b)).subtract((BigDecimal(4)).mult(a).mult(c));

This doesn’t look awful, but saying that it’s as readable as the normal arithmetic example is wrong. You could try to make it as neat and pretty as you can by commenting and indenting and spreading it out. I would, within reason. Do you think that this still doesn’t look bad? Then try doing the cubic formula. Or the quartic. The syntax is going to get in your way.

For big or complex implementations, this can be a pain in the ass. It becomes its own issue for the programmer, and gets directly in the way of actually solving problems.

People are the Problem

What is the problem? The cop-out answer is “People!”. To elaborate, we first need to look at the reasons that programming languages exist.

• So that people can efficiently talk to the computer.
• So that people can read how other people talk to the computer.

That’s it. There are no more reasons. If you think there might be, consider whether your reason is a reason or a consequence: I.E. programming language a has a problem, and programming language b was created to solve that problem. Programming languages help us quickly define and solve problems, and they exist so that other people can easily work on the problems based on what we wrote. Operator overloading deals directly with the readability of a language.

On one hand, overloading is very useful. For example, it fits perfectly into the C++ paradigm; the programmer does a little bit more work so that the user doesn’t have to. It fits well into Python’s paradigm, as it lets you get things done. If I knew anything about Ruby (and I’m reading enough Ruby blogs that it looks like I might start this summer when I have free time), it might fit into that.

It’s entirely syntactic sugar, and exists so that humans don’t yell “UGGGGH!” when they have to type in a huge formula for arbitrary precision arithmetic. If you have a BigInteger, why shouldn’t you be able to overload the + operator?

On the other hand, people will take any advantage that you give them, and they will abuse the hell out of it. They will either forget to update comments when they change the class, or they might just directly lie. They will swear on a stack of Bibles not to modify the data of a member you just passed, and then will use a const_cast<> and do it anyways. They will make gigantic utility classes named Utility that performs every function they know of. They will create 75 overrides of the same function that do entirely different things. All of these are supported by Java and/or C++, and the language does nothing to stop it.

All of these abuses are very easy for a person to perpetrate. We’ve all done at least one at some point or another. Our programming languages allow abuses with no hesitation, and some of these are committed extremely frequently. You can’t even remove the possibility of these abuses because some things, like commenting, are free-form, and could contain anything.

The Solution to Java’s Woes

I always feel bad complaining about something without trying to come up with a solution (one of the skills from my reading comprehension toolkit) so I tried to develop a Java-y solution that lets you overload operators while still “protecting the programmer from himself”. My solution is based on a single premise and two added constructs.

If we let the programmer override the base functions multiply(), divide(), subtract(), and add(), they will be allowed to use the overloaded operators (it’s not my fault/problem the designers of ArrayList used add instead of append() or insert()). For our discriminant example, this means that we are able to write as we would expect to if BigDecimal had multiply overridden. It will just automatically be called.

Now, here is the premise that will hold it all together.

• You can only use type a‘s operators with other objects of type a.

In order to make this useful, a second construct will be added to classes, the convert() construct. Let’s say the user wants to add two different types, such as the following example:

BigDecimal a;
BigInteger b;
a = a + b;

The user will have to override the convert() method in BigDecimal. The class would end up looking like this:

class BigDecimal{
    public static BigDecimal add(BigDecimal a){
        // ...
    }
    public static BigDecimal convert(BigInteger a){
        // ...
    }
}

The example would then be expanded to the following:

BigDecimal a;
BigInteger b;
a = a.add(BigDecimal.convert(b));

There we go, it’s easy! The Java compiler/interpreter can automatically perform this work just as it does for the String. It’s really no different, the mechanism is already built into the language. All that’s missing is order of operations, and that could easily be taken care of by processing the lines with a few passes.

If you don’t like this, what’s your way?