Comments for bb-generations blog

Comment on Java needs operator overloading by Emul

Emul — Fri, 20 Jan 2012 14:25:46 +0000

I’ve been a developer for nearly 40 years, mostly in the engineering and scientific realm. Of course COBOL was useless for these types of applications so we did a lot in Assembly language. When WATFOR finally came out we could use Fortran for our needs. And finally C++ became the language of choice. I had high hopes for Java, but they were soon dashed after I saw many Java forum posts being shot down by the MVPs and experts at Sun. All we wanted was operator overloading for complex numbers, matrices, quaternions, and vectors. It’s a simple request. No changes to the runtime or JRE are needed. But over and over again the requests from the engineering and scientific community were decried.

The powers-that-be gave pitiful excuses such as “That’s just syntactic sugar.” Well then tell me what isn’t? Do you toggle your programs into the box in binary? Everything beyond that IS syntactic sugar. It’s not a would-be-nice-if request, it’s very basic and essential – a huge missing capability in Java.

Others claimed that somebody could overload the addition operator so that it performs division! Hmm. Well heck, I could overload println() so that it deletes all of the files in user-land; and that’s without operator overloading. We’re not asking to be able to overload the scoping operator – just math, indexing, and assignment. It’s just syntax – but important syntax. If you are a business/website developer you may not appreciate the criticality, but imagine that somebody takes away java.net/java.web and makes you use JNI to access sockets! I’ve written many apps with thousands of lines of matrix math.

(I guess if you’re a business-app developer, the engineering and scientific world looks scary and strange – something to actively avoid.)

So most of us left for greener pastures – often to Microsoft C# where we could do math beyond simple arithmetic without writing illegible code. After a few years away from Java I have now revisited these forums only to discover that nobody is asking for operator overloading anymore – at least not in the past few years. Why not? It’s not lack of interest. The rest of us were just smart enough to abandon ship when it made sense. So I did some research. Try to search for engineering and scientific libraries and apps in Java, then do the same for .NET. There are some Java academic projects, but not many serious products out there. The few that exist are typically rudimentary or make use of underlying C/C++ code via JNI. It seems as if almost nobody is using Java for anything but business apps, most typically websites. Graphical games, likewise – switch to .NET if you want 3D graphics, finite element analysis, solid modeling, or constructive solid geometry. Oracle/Sun is deliberately shutting out a quarter of their potential market – and it’s an important segment.

Note that this is not intended to be an insult but, rather, as advice. General Patton was once advised that there was scuttlebutt about him going around. He responded, “Thanks, but I don’t worry when I hear scuttlebutt – I worry when I stop hearing it.” Well Oracle/Sun – after looking at your forums it seems that you have stopped hearing the scuttlebutt. So my only question for you remains: “Is Java trying to be the COBOL of the 21st century?”

Comment on Java needs operator overloading by Daniel

Daniel — Thu, 01 Sep 2011 14:54:29 +0000

An manchen Tagen möcht ich Leuten die gegen Operatorüberladung sind einfach ins Gesicht schlagen. Heute ist soeiner.
Graphikprogrammierung wird zu einer richtig hässlichen Sache wenn man Matrix und Vektoroperatoren nicht definieren kann aber noch schlimmer ist, dass wir im Unternehmen gerade das float primitive durch BigDecimal sollen. Wir sind echt am Überlegen auf die Genauigkeit zu pfeifen obwohl sie eigentlich erforderlich ist damit wir uns nicht mit .mul(), .add() usw. rumschlagen müssen.

===
Operator-Überladung ist immer böse, weil es verschleiert, was hinter dem Code steckt.
===
Das macht jeder Methodenaufruf. Nur weil es Leute gibt die mit dem + operator Objekte multiplizieren ist das noch lang kein Grund operatorüberladung wegzulassen. In jedem Methodenaufruf kann genausoviel blödsinn gemacht werden. Operatoren sind nichts anderes als Methoden.

Comment on Java: Loading a SVG into a BufferedImage by Tyron

Tyron — Wed, 27 Jul 2011 23:17:37 +0000

Funny, I just got in contact with batik as well recently, for converting browser generated charts in svg. Though I avoided its use by converting the svg to a canvas with the js lib canvg, which in return can be saved as png directly.

Comment on Java needs operator overloading by bb-generation

bb-generation — Mon, 13 Jun 2011 09:26:01 +0000

Mit Operator Überladung ist es wie mit Klassenvererbung, Methoden-Namensgebung, usw. Man muss das ganze sinnvoll einsetzen.
[] bei einem Set zu überladen macht keinen Sinn, bei einer Map hingegen sehr wohl.
Eine Map ist ja eine eine eindeutige Beziehung A->B (wobei jedes A nur einem B zugeordnet ist). Folglich macht map[A] natürlich Sinn und es spricht auch nichts dagegen es einzusetzen.
Folglich gilt natürlich: Überlade Operatoren dann, wenn es sinnvoll ist und es dem Entwickler ohne groß nachzuschauen klar ist, was passiert. In den meisten Fällen, die ich bei guten libraries gesehen habe, ist dies der Fall.

Interessanter Punkt mit den Referenzen-Vergleich. Daran hatte ich wirklich nicht gedacht.
C++ umgeht halt das Problem, indem man klar den Unterschied zwischen Objekt und Pointer hat. In Java besteht da eine gewisse Transparenz.

Comment on Java needs operator overloading by Tobias

Tobias — Sun, 12 Jun 2011 23:51:46 +0000

Operator-Überladung ist immer böse, weil es verschleiert, was hinter dem Code steckt. Eins der größten Probleme von C++ ist, dass man ein Stück Code ohne Kontext nicht verstehen _kann_, weil durch z.B. Operator-Überladung der identische Code einmal dies oder einmal etwas ganz anderes bedeuten kann. (C++ ist kontext-abhhängig.)

Ich durfte mal an einem Framework (C++) mitarbeiten, bei dem der Hauptentwickler ein Verfechter von Templates und Operator-Überladung war. Glaub mir, das macht keinen Spaß. Selbst in einfachen Fällen wie in deinem []-Beispiel ist der resultierende Code verwirrend. Man _muss_ wissen, dass die verwendete Klasse den []-Operator überlädt _und_ was die Klasse in dem Fall tut. Das ist bei [] ja nun nicht immer so klar. (Was macht der Operator z.B. bei einer Map? Oder bei einem Set?) Man braucht also Kontext und Dokumentation. Das ist schlecht.

Dein Beispiel mit den Integer-Objekten ist eher weniger gut. Der ==-Operator ist klar definiert: Er vergleicht Objekt-Referenzen bzw. bei primitiven Datentypen den Wert.

Nur weil es Klassen gibt, die primitive Datentypen wrappen können, heißt das ja nicht, dass der ==-Operator in diesem speziellen Fall eine andere Funktion haben sollte. Wenn man Objekt-Referenzen vergleicht, dann ==, wenn man Objekt-Inhalte vergleicht, dann equals().
Man kann jetzt natürlich trefflich darüber streiten, ob es bei der Spezifikation von Java nicht sinnvoller gewesen wäre, primitive Datentypen gleich als Objekte zu verstehen. Nun ist es aber nicht so, und daher sind auch die Operatoren entsprechend anzuwenden.

Und selbst wenn man den ==-Operator für z.B. Integer jetzt ändern würde (wenn man könnte): Wie vergleicht man dann Referenzen? Es kommt ja durchaus mal vor, dass man auch Integer-Referenzen vergleichen möchte. Dafür brauchte man dann plötzlich noch einen Operator, oder gar eine spezielle Methode. Das klingt für mich nicht so sinnvoll, um ehrlich zu sein. Einheitlichkeit ist bei Programmiersprachen wichtig.