3 ms·

I will die on the hill that Java is inferior because it doesn’t have native support for unsigned numerics.

rf15 1y ago
I'm doing Java for my main work, and boy, this still doesn't sit right with me after decades in the space. just give me my properly unsigned bytes, please
- pron 1y ago
  If x is a "properly unsigned" byte that has the value 1, what is the value of `x - 2 > 0` and why? The choice of having unsigned types or not is always one of the lesser evil, and in a language where emitting signals directly to hardware ports is not a primary use case, the argument that not having these types is the lesser evil carries a lot of merit.
layer8 1y ago
I used to think that way too, but there’s a good argument to be made that overflowing your integer types to negative values instead of to small (or large) positive values avoids a lot of silent bugs you’d otherwise have with unsigned types. A language solving that would need to work with static proofs of non-overflow, and have any desired overflow to be explicit. Java in the meantime has gained all the unsigned operations as methods in the Integer and Long classes, so the relatively rare cases when you need them are straightforward to handle. The only real annoyance is that byte is signed. At least there’s a bit of unsigned support in the Byte class now. Lastly, minor point, Java actually has an unsigned 16-bit integer type, called char.
hashmash 1y ago
The problem with having unsigned integer types is that it introduces new type conversion issues. If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Or vice versa? A smaller set of primitive types is preferred, since it has fewer conversion issues. Unsigned integer types are only really necessary when dealing with low-level bit manipulation, but most programs don't do this. The lack of unsigned integers makes low-level stuff a bit more difficult, but it makes the language as a whole much easier. It's a good tradeoff.
- binarymax 1y ago
  Literally every other language with unsigned types handles this just fine?
  - pron 1y ago
    By no means do C or C++ handle unsigned types just fine. In fact, they're widely recognised as a source of problems even by those who think they're useful (when used carefully).
  - hashmash 1y ago
    I guess it depends on what "just fine" means. What happens when a conversion is applied? Is there silent data corruption (C), or is there an exception (Ada, D) or perhaps a panic (Rust, Zig)? Is the behavior dependent on compiler flags? Keeping unsigned integer types out of the language makes things much simpler, and keeping things simple was an original design goal of Java.
- TuxSH 1y ago
  > If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Mandate 2's complement be used. > Unsigned integer types are only really necessary when dealing with low-level bit manipulation They also give one more bit of precision, useful when dealing with 32-bit integers (or below)
pron 1y ago
Other than unsigned types for FFI or wire formats (which Java supports just fine) or for bitfields (which Java doesn't have), what do you want unsigned numerics for? The risk of unsigned types (even without the C or C++ issues around mixing with signed types) is that too many people make the mistake of using them to express the invariant of "a number that must be positive", which modular arithmetic types are a really bad fit for. One possible use is for a memory-efficient storage of small positive values, say in a byte. But then you have to make a choice between forcing the value into a signed type for arithmetic (which Java easily lets you do with Byte.toUnsignedInt) and allowing signed and unsigned types to be mixed.

rf15 1y ago

I'm doing Java for my main work, and boy, this still doesn't sit right with me after decades in the space. just give me my properly unsigned bytes, please

pron 1y ago
If x is a "properly unsigned" byte that has the value 1, what is the value of `x - 2 > 0` and why? The choice of having unsigned types or not is always one of the lesser evil, and in a language where emitting signals directly to hardware ports is not a primary use case, the argument that not having these types is the lesser evil carries a lot of merit.

layer8 1y ago

I used to think that way too, but there’s a good argument to be made that overflowing your integer types to negative values instead of to small (or large) positive values avoids a lot of silent bugs you’d otherwise have with unsigned types. A language solving that would need to work with static proofs of non-overflow, and have any desired overflow to be explicit. Java in the meantime has gained all the unsigned operations as methods in the Integer and Long classes, so the relatively rare cases when you need them are straightforward to handle. The only real annoyance is that byte is signed. At least there’s a bit of unsigned support in the Byte class now. Lastly, minor point, Java actually has an unsigned 16-bit integer type, called char.

hashmash 1y ago

The problem with having unsigned integer types is that it introduces new type conversion issues. If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Or vice versa? A smaller set of primitive types is preferred, since it has fewer conversion issues. Unsigned integer types are only really necessary when dealing with low-level bit manipulation, but most programs don't do this. The lack of unsigned integers makes low-level stuff a bit more difficult, but it makes the language as a whole much easier. It's a good tradeoff.

binarymax 1y ago
Literally every other language with unsigned types handles this just fine?
- pron 1y ago
  By no means do C or C++ handle unsigned types just fine. In fact, they're widely recognised as a source of problems even by those who think they're useful (when used carefully).
- hashmash 1y ago
  I guess it depends on what "just fine" means. What happens when a conversion is applied? Is there silent data corruption (C), or is there an exception (Ada, D) or perhaps a panic (Rust, Zig)? Is the behavior dependent on compiler flags? Keeping unsigned integer types out of the language makes things much simpler, and keeping things simple was an original design goal of Java.
TuxSH 1y ago
> If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Mandate 2's complement be used. > Unsigned integer types are only really necessary when dealing with low-level bit manipulation They also give one more bit of precision, useful when dealing with 32-bit integers (or below)

pron 1y ago

Other than unsigned types for FFI or wire formats (which Java supports just fine) or for bitfields (which Java doesn't have), what do you want unsigned numerics for? The risk of unsigned types (even without the C or C++ issues around mixing with signed types) is that too many people make the mistake of using them to express the invariant of "a number that must be positive", which modular arithmetic types are a really bad fit for. One possible use is for a memory-efficient storage of small positive values, say in a byte. But then you have to make a choice between forcing the value into a signed type for arithmetic (which Java easily lets you do with Byte.toUnsignedInt) and allowing signed and unsigned types to be mixed.