5 ms·

There are five points on page 3: 1. Linguistically legislated exact reproducibility is at best mere wishful thinking. 2. Of two traditional policies for mixed

by amock 13y ago

There are five points on page 3: 1. Linguistically legislated exact reproducibility is at best mere wishful thinking. 2. Of two traditional policies for mixed precision evaluation, Java chose the worse. 3. Infinities and NaNs unleashed without the protection of floating-point traps and flags mandated by IEEE Standards 754/854 belie Java’s claim to robustness. 4. Every programmer’s prospects for success are diminished by Java’s refusal to grant access to capabilities built into over 95% of today's floating-point hardware. 5. Java has rejected even mildly disciplined infix operator overloading, without which extensions to arithmetic with everyday mathematical types like complex numbers, intervals, matrices, geometrical objects and arbitrarily high precision become extremely inconvenient.

kaoD 13y ago
#1-#4 don't give much information about the real problem. #5 is just a matter of convenience. I'm sure the Java team gave a long thought to adding operator overloading, and I can see why they choose not to include it (Java is meant to be straightforward, with as little magic as possible). The first 20 pages or so are too much "blahblah" about Java, not much about how it's hurting everyone.
- jerf 13y ago
  #5 isn't a matter of convenience if you're trying to do heavy mathematical operations in Java. Deviation between conventional notation and programming notation is a real problem, because it's a place where bugs can hide. However, I would be very sympathetic to the argument that the solution is "Don't do that". In 1998 and today, for what may be different reasons but still comes to the same outcome, Java is not a language intended for highly mathematical computations. It's probably better just to not pretend that it is one, than to try to force it in. Nor would I even consider this a criticism of Java (though I personally dislike it); compared to its focus area, trying to support heavy-duty math would be a tiny little niche to it that would take wildly disproportionate amounts of effort to support. Let people who care about that niche operate in it. My only point of agreement is that it is true that you ought to be able to get easy feedback about NaN and other failures, indeed precisely because in Java you are unlikely to be doing the sorts of calculations in which those are expected possibilities. $NaN or "infinity hours billed" is something you generally want an exception for, ASAP. It would have been better to write that in as a requirement for the VM and slowly emulate it on the few platforms that didn't natively support it than leave it out. (A brief google search suggests Java still doesn't support this, even today. If I got that wrong... great! I'm glad it has come on board, but I stand by the idea that it should have been in there from day 1, which is the real point I have here.)
MrBuddyCasino 13y ago
Interestingly, omitting infix operator overloading was something the language designers were forced to do for time-to-market reasons, and in hindsight, is one of their biggest regrets. I don't have the source, I think it was in a Josh Bloch interview.
- Aardwolf 13y ago
  So why not add them to a next Java version?

by amock 13y ago

kaoD 13y ago

#1-#4 don't give much information about the real problem. #5 is just a matter of convenience. I'm sure the Java team gave a long thought to adding operator overloading, and I can see why they choose not to include it (Java is meant to be straightforward, with as little magic as possible). The first 20 pages or so are too much "blahblah" about Java, not much about how it's hurting everyone.

jerf 13y ago
#5 isn't a matter of convenience if you're trying to do heavy mathematical operations in Java. Deviation between conventional notation and programming notation is a real problem, because it's a place where bugs can hide. However, I would be very sympathetic to the argument that the solution is "Don't do that". In 1998 and today, for what may be different reasons but still comes to the same outcome, Java is not a language intended for highly mathematical computations. It's probably better just to not pretend that it is one, than to try to force it in. Nor would I even consider this a criticism of Java (though I personally dislike it); compared to its focus area, trying to support heavy-duty math would be a tiny little niche to it that would take wildly disproportionate amounts of effort to support. Let people who care about that niche operate in it. My only point of agreement is that it is true that you ought to be able to get easy feedback about NaN and other failures, indeed precisely because in Java you are unlikely to be doing the sorts of calculations in which those are expected possibilities. $NaN or "infinity hours billed" is something you generally want an exception for, ASAP. It would have been better to write that in as a requirement for the VM and slowly emulate it on the few platforms that didn't natively support it than leave it out. (A brief google search suggests Java still doesn't support this, even today. If I got that wrong... great! I'm glad it has come on board, but I stand by the idea that it should have been in there from day 1, which is the real point I have here.)

MrBuddyCasino 13y ago

Interestingly, omitting infix operator overloading was something the language designers were forced to do for time-to-market reasons, and in hindsight, is one of their biggest regrets. I don't have the source, I think it was in a Josh Bloch interview.

Aardwolf 13y ago
So why not add them to a next Java version?