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$
  • 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$ – David Richerby Apr 28 '14 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 '14 at 22:49
  • $\begingroup$ I think the question would be better off on Software Engineering, though. $\endgroup$ – Raphael Jun 13 '14 at 17:16
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$
  • 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 '14 at 17:15
  • $\begingroup$ Yuval, I am re-reading this answer in 2018. Thanks for the wonderful answer. $\endgroup$ – Zedaiq Jul 6 '18 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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