On Tue, Apr 26, 2022 at 10:31 AM Dan Smith <daniel.sm...@oracle.com> wrote:
If the expectation is that a typical programmer is going to look over their > menu of types and choose between 'int', 'long', or 'Integer128.val', I > think we've heavily biased them against the third one. The syntactic > overhead is just too much. > But this bias affects only the specific slice of use cases that both (a) *should *use `Integer128.val` but (b) can get by fine with using `int`. I think that slice is probably marginal. And a tool could come by and fix up the code to squeeze more performance out of it later. I think our success will come from widespread high-performance use of these > classes. Like how 'int' works. If the L types are not "high-performance" (a > subjective measure, I know), and the Q types are pain to use, I worry that > won't be perceived as successful. (Either "Valhalla is a pain to use" or > "Valhalla rarely delivers the promised performance".) > As long as we are distinguishing the "perception issue" from the reality and weighting the perception issue appropriately -- which is not zero, for sure. I'm thinking about this test more from a clean slate perspective, I think: > rephrased, in a new language (something like Kotlin, say), could we leave > out 'int', and convince people to do everything with 'Integer', or in > performance-sensitive cases say 'Integer.val'? Would that language be > perceived as worse (on either performance or syntactic grounds) than Java? > I think I would insist that `.val` be spelled with only one additional character... or even that the value type be generated as the snake_case form of the name! -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
