Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Kevin Bourrillion]

On Tue, Apr 26, 2022 at 10:31 AM Dan Smith <daniel.smith at 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. | kevinb at google.com