5 ms·

This post has an introduction that is noteworthy of its disrespect towards proponents of unsigned integers. "Oftentimes it’s a novice coming from C/C++ or C# w

by ablob 4y ago

This post has an introduction that is noteworthy of its disrespect towards proponents of unsigned integers. "Oftentimes it’s a novice coming from C/C++ or C# who has worked with unsigned types before, or one who wants to guarantee no negative numbers in certain situations." This is a neutral observation first and foremost. By itself there is nothing wrong with it. I would expect newcomers of a language to miss features of where they came from as well. Although it should be noted that this statement is only a gut-feeling without proper statistics to back it up. What irks me is what comes next: "Said novice C/C++/C# programmer typically does not fully understand the semantics and ramifications of unsigned integers in C/C++/C# to begin with." Not only does he presume that the newcomer does not fully understand the semantics and ramifications of unsigned values in java. He also asserts that this is the case for the language that they came from. How do you expect a reasonable debate to continue from here on out? Every disagreement is settled by just stating, that the proponent just doesn't understand the problem. Now what if they understand the semantics and ramifications and still want that feature? Does a world exist for the author in which this is the case? Moreover, the article is pretentious as well. The semantics of unsigned integers in java hasn't been decided yet, so you either have to argue against each proposed model or in general. Here, a model in which implicit type conversion from unsigned to signed values is argued against. Other possibilities are not considered. At this point I am inclined to just step away, as there is no information about both the semantics that is being argued against (method: find it by reading it) and, whether it is the only model proposed. There is no insight to be had except that the author doesn't want unsigned integers and is content with how it works as is (with an asterisk for bytes). I do believe that the people in favour of the addition have to make a case for it. But I also thought that we were beyond arguments of the "you're holding it wrong" kind. As silly as it may sound, an argument like this makes me consider the other side immediately. And I say that as someone who never felt the need for unsigned integers in Java.

nayuki 4y ago
What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Namely: https://www.nayuki.io/page/summary-of-c-cpp-integer-rules https://www.nayuki.io/page/summary-of-c-cpp-integer-rules , https://en.cppreference.com/w/cpp/language/types https://en.cppreference.com/w/cpp/language/types , https://en.cppreference.com/w/c/language/conversion#Integer_conversions https://en.cppreference.com/w/c/language/conversion#Integer_... , https://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions https://en.cppreference.com/w/c/language/conversion#Usual_ar... Never mind the fact that the vast majority of C/C++ programmers don't appreciate the fact that signed overflow in their languages is undefined behavior and can result in anything from correct behavior to complete unpredictable garbage. It's easy to argue for adding unsigned to Java because "I want this feature"; it's harder to argue against it because "I don't want others to use this feature / I don't like how this feature interacts with existing features". Another example of not understanding types, did you know that Rust's usize can be as small as 16 bits? And that even on a 32-bit system, objects are limited to 2 GiB in size, not 4 GiB? https://stackoverflow.com/questions/32324794/maximum-size-of-an-array-in-32-bits https://stackoverflow.com/questions/32324794/maximum-size-of... > The semantics of unsigned integers in java hasn't been decided yet I think they have been decided. Java SE 8 added functions to treat bits as unsigned and perform operations (e.g. Integer.divideUnsigned(), Long.toStringUnsigned()). They might have also stated that it was a non-goal to add unsigned primitive integer types to the language. For what it's worth, I am aware that the lack of unsigned integers in Java is a very contentious topic for decades, and the loudest voices are definitely on the pro-unsigned side. My favorite example is this thread: https://stackoverflow.com/questions/430346/why-doesnt-java-support-unsigned-ints https://stackoverflow.com/questions/430346/why-doesnt-java-s...
- rcoveson 4y ago
  > What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Who cares? You could ask the same question about operator precedence, and the answer to both is similar: If it's unclear to you or those who might read your code, just be more explicit than strictly necessary. Handle or assert cases of possibly overflow. And by all means, you don't have to mimic the C/C++ implicit casting rules. If something's a potential pitfall, just make it an explicit cast (like `long` to `int` already is). The status quo has some huge pitfalls of its own. `uint64` is out there, whether certain Java folks like it or not. It's there in protobuf, it's there in your databases, it's there in your FFI. This leaves people who have to interoperate with things from Java with the choice of either using `long` and hoping beyond hope your users read the docs, or using BigInteger and taking the accompanying performance hit, plus more correctness problems if your users try to operate on the value and take it outside its range. The Java version of unsigned integers could completely disallow casting to and from signed integers and they would still be a very useful addition to the language. Instead what's going to happen is we're going to get JEP 401 and you'll have a hundred different uint64 primitive classes that are exactly the same as each other except that they have different types. That or we'll get lucky and they'll add one to the standard library, at which point everybody who confidently asserted that adding unsigned integers to Java was a bad idea will have to rationalize to themselves that it doesn't really constitute adding them to the language because they're not in the bytecode, or they're not accessible without an import, or something.
rcoveson 4y ago
The author makes it clear from the first paragraph that they're not trying to argue with the strong case for unsigned integers; they'd rather argue against the novice's case. I'd say that in this contest betweeen the author and somebody described as literally not understanding the implications of what they are asking for, the author might have eked out a victory. Now they can move on to the winner's bracket and argue against an intermediate-level engineer.
- junon 4y ago
  The title itself is incredibly aggravating. "Considered harmful" is the most passively arrogant phrase with the exception of Dijkstra's original paper, and it really irks me when authors use it.
  - ksherlock 4y ago
    Dijkstra's chosen title was "A Case against the GO TO Statement". Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...
    - junon 4y ago
      TIL. So, it's always been and will forever be arrogant in all cases. Good to know.
  - j16sdiz 4y ago
kevin_thibedeau 4y ago
The people that advance these notions generally don't understand how computer arithmetic works and are lost in a scholarly fantasy world where they think integers solely exist on an unbounded number line. Anything that violates this predicate must be wrong because it forces them to be careful about edge cases.
throwaway2037 4y ago
When I was a new C++ programmer, I thought I was being safe by using unsigned int parameters instead of signed ints. "Oh, this will prevent negative values from being passed. I guess the compiler or magical elf inside my computer will prevent it." I was a little emotionally damaged to learn that ((unsigned int) -1) resulted in a ginormous value. So yeah, it's definitely a thing for newbies to associate auto-magical properties to the keyword unsigned. And I have heard this story repeated to me by good developers many times. We laugh about it together -- "Me too!"

by ablob 4y ago

nayuki 4y ago

What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Namely: https://www.nayuki.io/page/summary-of-c-cpp-integer-rules https://www.nayuki.io/page/summary-of-c-cpp-integer-rules , https://en.cppreference.com/w/cpp/language/types https://en.cppreference.com/w/cpp/language/types , https://en.cppreference.com/w/c/language/conversion#Integer_conversions https://en.cppreference.com/w/c/language/conversion#Integer_... , https://en.cppreference.com/w/c/language/conversion#Usual_arithmetic_conversions https://en.cppreference.com/w/c/language/conversion#Usual_ar... Never mind the fact that the vast majority of C/C++ programmers don't appreciate the fact that signed overflow in their languages is undefined behavior and can result in anything from correct behavior to complete unpredictable garbage. It's easy to argue for adding unsigned to Java because "I want this feature"; it's harder to argue against it because "I don't want others to use this feature / I don't like how this feature interacts with existing features". Another example of not understanding types, did you know that Rust's usize can be as small as 16 bits? And that even on a 32-bit system, objects are limited to 2 GiB in size, not 4 GiB? https://stackoverflow.com/questions/32324794/maximum-size-of-an-array-in-32-bits https://stackoverflow.com/questions/32324794/maximum-size-of... > The semantics of unsigned integers in java hasn't been decided yet I think they have been decided. Java SE 8 added functions to treat bits as unsigned and perform operations (e.g. Integer.divideUnsigned(), Long.toStringUnsigned()). They might have also stated that it was a non-goal to add unsigned primitive integer types to the language. For what it's worth, I am aware that the lack of unsigned integers in Java is a very contentious topic for decades, and the loudest voices are definitely on the pro-unsigned side. My favorite example is this thread: https://stackoverflow.com/questions/430346/why-doesnt-java-support-unsigned-ints https://stackoverflow.com/questions/430346/why-doesnt-java-s...

rcoveson 4y ago
> What percentage of C and C++ programmers do you think really understand all the rules regarding integer types in C? Who cares? You could ask the same question about operator precedence, and the answer to both is similar: If it's unclear to you or those who might read your code, just be more explicit than strictly necessary. Handle or assert cases of possibly overflow. And by all means, you don't have to mimic the C/C++ implicit casting rules. If something's a potential pitfall, just make it an explicit cast (like `long` to `int` already is). The status quo has some huge pitfalls of its own. `uint64` is out there, whether certain Java folks like it or not. It's there in protobuf, it's there in your databases, it's there in your FFI. This leaves people who have to interoperate with things from Java with the choice of either using `long` and hoping beyond hope your users read the docs, or using BigInteger and taking the accompanying performance hit, plus more correctness problems if your users try to operate on the value and take it outside its range. The Java version of unsigned integers could completely disallow casting to and from signed integers and they would still be a very useful addition to the language. Instead what's going to happen is we're going to get JEP 401 and you'll have a hundred different uint64 primitive classes that are exactly the same as each other except that they have different types. That or we'll get lucky and they'll add one to the standard library, at which point everybody who confidently asserted that adding unsigned integers to Java was a bad idea will have to rationalize to themselves that it doesn't really constitute adding them to the language because they're not in the bytecode, or they're not accessible without an import, or something.

rcoveson 4y ago

The author makes it clear from the first paragraph that they're not trying to argue with the strong case for unsigned integers; they'd rather argue against the novice's case. I'd say that in this contest betweeen the author and somebody described as literally not understanding the implications of what they are asking for, the author might have eked out a victory. Now they can move on to the winner's bracket and argue against an intermediate-level engineer.

junon 4y ago
The title itself is incredibly aggravating. "Considered harmful" is the most passively arrogant phrase with the exception of Dijkstra's original paper, and it really irks me when authors use it.
- ksherlock 4y ago
  Dijkstra's chosen title was "A Case against the GO TO Statement". Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...
  - junon 4y ago
    TIL. So, it's always been and will forever be arrogant in all cases. Good to know.
- j16sdiz 4y ago

kevin_thibedeau 4y ago

The people that advance these notions generally don't understand how computer arithmetic works and are lost in a scholarly fantasy world where they think integers solely exist on an unbounded number line. Anything that violates this predicate must be wrong because it forces them to be careful about edge cases.

throwaway2037 4y ago

When I was a new C++ programmer, I thought I was being safe by using unsigned int parameters instead of signed ints. "Oh, this will prevent negative values from being passed. I guess the compiler or magical elf inside my computer will prevent it." I was a little emotionally damaged to learn that ((unsigned int) -1) resulted in a ginormous value. So yeah, it's definitely a thing for newbies to associate auto-magical properties to the keyword unsigned. And I have heard this story repeated to me by good developers many times. We laugh about it together -- "Me too!"