Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Java chose not to implement (general) operator overloading because it's really hard to do right. We're left with just a fluent syntax for appending text to strings.

Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

Python's operator overloading works remarkably well given that it has a very simple model (always look to the left hand side to decide how to interpret the operator.) C++ on the other hand ought to make anybody skeptical of the idea, but C++ would make anybody thoughtful and sensitive question the idea of computers entirely.

View on HN

> Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

I think ALGOL was first, in the ALGOL 60 Report (https://en.m.wikipedia.org/wiki/ALGOL_60#History). COBOL may have had a good spec around that time, too.

There were older languages with specifications, but those specifications were looser, with languages partly defined by their prime implementation.

Well, neither Java, Common Lisp nor ALGOL60 support operator overloading, so there does seem to be a trend there.

Common Lisp in fact, as most lisps, has no support for "operators" in the infix sense at all. If you have a need for a very algebra-heavy portion in your program (say, a linear algebra library), the best idea would be to define a DSL for that particular algebra - especially since this will give you much more control over efficient evaluation than using the built-in evaluation order.

A good example of the limitations of simplistic operator overloading is matrix algebra: A+B•C can be computed efficiently as a ternary operation, more efficiently than doing A+B then multiplying the result by C. Now of course, you can implement this in C++ by having operator+() return some kind of matrix_addition object, and then defining the efficient operations in operator*(matrix_addition, matrix) etc, but that is much more roundabout than defining a simple addAndMul(A,B,C), or an explicit optimizing DSL.

There are reader macros which provide a more math-like notation. Those are translating the math syntax into Lisp s-expressions at read-time.

Yes, that's the DSL concept I was talking about.

The lack of operator overloading makes it impossible to implement new numeric types in a consistent way. For example imaginary numbers or numbers with units.

You can make the case that both intX (x=16, 32, 64) and floating point are bad for general purpose computing. Like Common LISP and Python, Java has bigints and rationals in the stdlib, but Java makes you use non-operator syntax to get at them. Contrast that to Clojure which puts them on your fingertips.

Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)

If there's no implementation on the left, python then looks on the right.

Reply on news.ycombinator.com