5 ms·
Say what you want about COBOL, but at least it had a built-in data type for decimal numbers (looking at you, Java).
by Kristine1975 11y ago
Say what you want about COBOL, but at least it had a built-in data type for decimal numbers (looking at you, Java).
- jestar_jokin 11y agoBigDecimal doesn't count? (I guess because it's "Big" rather than efficient.)
- Kristine1975 11y agoIt's not built-in ;-) Also its syntax is horrible: d = a.add(b.mul(c)); instead of d = a + b * c; Even COBOL's COMPUTE D = A + B * C. was clearer than Java's OOP notation.
- JulianMorrison 11y agoJava's decision to privilege "primitive" types was a failure of imagination. They decided they didn't want operator overloading but didn't make any way to replace it. They should retrofit it as follows: interface Addable<T> { T add(T other); } And then make the + apply to any Addable, which can be defined for the boxed primitives. And so on for the other operators.
- Jtsummers 11y agoIt's been a while since I Java'd, but wouldn't this still have problems when mixing types? A java string added to anything results in the toString() method being called. It doesn't matter if the string is before or after the + operator. How do you specify precedence in this new scheme short of an exponentially large `add` method handling all the cases. And each add method has to handle all the variety of cases.
- Kristine1975 11y agoMake it: interface Addable<RHS, Result> { Result add(RHS other); } The problem is hardly new though. Groovy is very Java-like and has operator overloading: http://groovy-lang.org/operators.html#Operator-Overloading http://groovy-lang.org/operators.html#Operator-Overloading
- andreasvc 11y agoWould be best to disallow mixing types I think, except for the legacy behavior with primitive types you describe. Those hidden conversions are a source of subtle bugs.
- nickpsecurity 11y agoExactly. I've been preaching for other languages to get that for years. Avoid many of these odd floating point issues, esp when handling money. On top of it, the POWER processors were wise enough to include a decimal unit to accelerate it.
- Kristine1975 11y agoThe IEEE 754 floating-point standard even includes decimal- instead of binary-based floating-point types, i.e. which can represent e.g. 0.1 accurately: https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_... I think this is what IBM's POWER CPUs implement. And there's even a proposal to add it to the C++ standard: http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.ht... And the C standard: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1312.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1312.pdf
- nickpsecurity 11y agoOh heck I didnt even know that. Yes, the IBM chips implement it on top of FPU with hardware/firmware combo. Googling POWER decimal gave me a PDF with floor plan and all. Their reasoning is that, unlike scientific community, most people use FPU's while thinking in and requiring decimal properties. So why not offer them a decimal unit, eh? Glad it might get into C++ standard.
- bitwize 11y agoI've deployed business apps in Scheme and used rational numbers for currency values.