4
$\begingroup$

Why operator overloading was included in Python and not in Java? How does one decide to include or exclude operator overloading in a programming language?

It is said here that operator overloading is excluded from Java to make the language simpler (for programmers, language and VM developers, etc.).

I don't understand why the same explanation doesn't work for excluding it in Python?

$\endgroup$
3
  • 5
    $\begingroup$ Programming language design is a part of computer science so I don't think this should be closed for being off-topic. $\endgroup$ Apr 28, 2014 at 16:39
  • $\begingroup$ Agreed with David Richerby. The answer (as Yuval points out) is that it's completely arbitrary in this case, but there's no reason for the uninitiated to know that. It could very well have been for a much more objective reason. $\endgroup$
    – Patrick87
    Apr 28, 2014 at 22:49
  • $\begingroup$ I think the question would be better off on Software Engineering, though. $\endgroup$
    – Raphael
    Jun 13, 2014 at 17:16

1 Answer 1

10
$\begingroup$

Operator overloading is an example of syntactic sugar — a notation that doesn't give any extra power but makes programming easier. I don't know the rationale for the decisions in Java and in Python, but see below. See also this answer on stackoverflow.

First, I would like to critique the page you were linking. Let's consider the points raised there one by one.

  1. Simplicity and cleanliness: It is claimed that operator overloading slows down the compiler and the JVM (!). This is non-sense. It's plain wrong for the JVM, since this is just syntactic sugar so it wouldn't affect the generated code at all. As for the compiler, the compiler is already equipped to parse infix operators and to resolve virtual methods, so supporting operator overloading won't make it more complex. On the flip side, operator overloading makes the Java code simpler and cleaner: compare a.add(b) to a+b.

  2. Avoid programming errors: It is claimed that non-standard semantics for operators might confuse programmers. Compare this to C++'s use of >> and << in streams. I think this point is valid but overstated. The same point could be made with regard to other conventions. It's up to the programmers to not abuse the capabilities of the language.

  3. JVM complexity: It is claimed that operator overloading complicates the JVM. As stated above, at the JVM level there would be absolutely no difference.

  4. Easy development of tools: It is claimed that operator overloading complicated the design of IDEs. The answer here is very similar to the answer to the first point. The only complication with operator overloading is that you have to figure out the type of the operands, but presumably if it makes any difference you would need to do it anyway since there are also several different number types, say integer and floating point.

A point which is not raised is that operator overloading might complicate optimization since certain algebraic identities hold for numbers but not in general. This criticism is wrong for the following reason: algebraic identities cannot in general be used even for floating-point computations, since order of operations makes a difference. So the compiler needs to determine the type of the operands anyway, and could easily abstain from optimizing user defined operators.

The Python philosophy is to supply the coders with the rope to hang themselves. If you're a good coder, you will use the rope for good, say for tying your bicycle in the train, rather than to hang yourself or anybody else. Python trusts programmers more than Java, by design. See the second point above.

Let me end this answer by quoting an excellent answer to the stackoverflow question mentioned above:

I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++.

James Gosling. Source: http://www.gotw.ca/publications/c_family_interview.htm

Many C++ design decisions have their roots in my dislike for forcing people to do things in some particular way [...] Often, I was tempted to outlaw a feature I personally disliked, I refrained from doing so because I did not think I had the right to force my views on others.

Bjarne Stroustrup. Source: The Desing and Evolution of C++ (1.3 General Background)

$\endgroup$
3
  • 2
    $\begingroup$ "It's up to the programmers to not abuse the capabilities of the language." -- and once you observe that programmers are obstinately bad at not doing this, you may want to build a language to be as robust against abuse as possible. Sometimes, having code that can be read by another person years later outweight slightly more verbose code. $\endgroup$
    – Raphael
    Jun 13, 2014 at 17:15
  • $\begingroup$ Yuval, I am re-reading this answer in 2018. Thanks for the wonderful answer. $\endgroup$
    – Zedaiq
    Jul 6, 2018 at 9:49
  • $\begingroup$ I would expect that operator overloading is not present in Java for the same reason that the preprocessor bit from C was not included. The language designers wanted to make certain that the code you see only have one meaning. (Or they just didn't need it in the initial versions when it was still Oak and just left it like that) $\endgroup$ Dec 16, 2020 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.