

Proposal for generics over primitives needs a rethink - StylifyYourBlog
http://mail.openjdk.java.net/pipermail/valhalla-dev/2014-December/000474.html

======
codeka
_> The cost of the C# approach is that existing classes could not be gradually
migrated to be generic; existing collections had to be effectively deprecated
and replaced, or a "flag day" had to be declared where all the code (library
and client) changes simultaneously. These are not options for us. At the risk
of being obnoxious, C# was able to get away with it because at the time, they
had a very small base of existing users and code and were not yet successful
enough to have to worry about compatibility._

The reason C# was able to do it is not because they had so few users that a
"flag day" was acceptable, it was because they went with the first option and
rewrote all their collections. C# did genetics right the first time, and
didn't end up in this bizarre type-erasing, half-ass world that Java find
itself in today.

------
matt2000
For reference, here's a fairly detailed response:
[http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-Dec...](http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-December/000475.html)

Site note: I liked how both authors took pains to be respectful in their
tones, keeps the focus on the issues at hand and avoids people getting
irritated with one another.

------
guelo
I thought the response was needlessly combatative,
[http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-Dec...](http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-December/000475.html)

~~~
zeendo
Agreed. Gavin's post didn't seem to acknowledge that this was a proposal and
seemed to belittle the work put into it...but I found Brian's overly defensive
(though I agree with his conclusion).

Having seen Brian's stewardship talk at ClojureConj, and now this, it seems
clear that he feels the need to be defensive against the non-Java JVM
languages out there.

------
diltonm
I vote for not making the language more complicated than it already is in Java
7. Oh but we have Java 8 with closures and stuff, well OK how about no more
complicated than Java 8. Please? Instead maybe introduce useful things that
make programmers more productive. How about implicit generics. Where this
whole mess of T and Any and <: extendsT< gobbldygook> melts away. Notice how a
new class extends Object automatically? It always has. Why do I have to muck
about with all the fancy and overly complex syntax. Give me the features of
all of that but abstract it away so I can just write what I need to and it
works implicitly. Either that or just leave the dang language alone and go
make some cool libraries.

~~~
Afforess
I am really rather tired of the appeal to simplicity that is often made in
language design. Simplicity is not a virtue in a programming language.
Consistency is a virtue, but not simplicity.

Simplicity is a tradeoff that takes away power and control from the programmer
and gives it to the computer. Computers don't need to be more powerful,
programmers do. The tradeoff is a poor one and rarely worth the little gained.

In this case, what do we gain by not adding primitive value types in Java? The
fact that you sleep better at night because the language is more "clean"? Why
should we want that? Sleep is definitely important, but the idea that a
language can be too complex is silly.

It does matter that new additions do remain consistent with the overall
architecture, but there is no reason to advocate less features simply because
you find the idea of learning something new disconcerting.

~~~
eropple
Agreed. I feel like a C# Stan in here at the moment, given how often I'm
speaking glowingly of it lately--I use it to make games but my day job is Ruby
and Scala!--but you can look at C# to see what moderately progressive (not
even "aggressive") iteration on a language to add more and more powerful
features in a smart, clean way would look like. Nobody's complaining about C#
having too many bells and whistles, honest.

------
eropple
The response by Brian Goetz[1] is kind of unpleasant and combative. Moreover,
the ideas in it kind of encapsulate why I'm growing more and more
uncomfortable with relying on the JVM to keep up with my needs in the future.

 _> The cost of the C# approach is that existing classes could not be
gradually migrated to be generic; existing collections had to be effectively
deprecated and replaced, or a "flag day" had to be declared where all the code
(library and client) changes simultaneously. These are not options for us._

This is why, despite doing it in my day job, I'm not high on the JVM's future
as it stands right now. Compatibility uber alles is _not_ a virtue, even
Microsoft gets that these days. Saying "on 1 Jan 2017 we're pushing Java 10,
and you will need to recompile your dependencies to upgrade" is not a bad
thing. No, many people won't upgrade immediately. That's true. But _they
already don 't_! It takes years for consumers to catch up with the newest
version of Java (for reasons that do not reflect well on those consumers). Why
should I, as a consumer, care about them? Why should I, as a consumer,
continue to use your product when you would care about laggards more than me?
I mean, Oracle's welcome to, it's their business, but why would I respond
positively to that?

But he says that a flag day means they "hate their users." No, it would mean
they are going to firewall off the damage laggards can do to their environment
and ecosystem. And for the sake of a healthy platform for the next decade I
would think they should do exactly that, because those laggards don't make the
ecosystem and the environment better.

And then, at the very end:

> And, feel free to prove us wrong! Try implementing the changes you are
> envisioning in the JVM, and show how they can get us to the goal!

Why should I, guy-who-works-for-Oracle? I'm not drawing a paycheck from
Oracle, who owns Java so utterly and wants to attack and damage related tools
and platforms (hi, Android), and guess what? I really don't need Oracle to fix
this because in 2015 I am going to have _options_. Microsoft is releasing an
open-source CLR for OS X and Linux and it's effectively substitutable for just
about anything I care to use (and, if I had to be honest, a combination of C#
and F# are probably better than even Scala for what I do). This is _Oracle 's_
problem and Oracle's ground to lose, not mine.

Two-thirds of my Github are C# and Ruby at this point, anyway, and I don't
even use C# for work.

[1] - [http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-Dec...](http://mail.openjdk.java.net/pipermail/valhalla-
dev/2014-December/000475.html)

~~~
skybrian
It sounds like you do hate Java's users. You dismiss the difficulty of
upgrading existing apps, which is an enormous amount of work, without even
making a rough estimate of how hard it would be. They are just "laggards" to
you. At least consider that others may have different values than you and
actually care about these people.

Sacrificing backward compatibility means adding pain for existing users in the
hope that the world will be better for new users. Splitting the community on
purpose has a cost; just look at python 3 for how painful this is.

Whether this makes sense depends very much on the size of your existing user
base and on the potential for growth. The users you gain by making a language
somewhat more elegant may not be worth the loss from the disruption.

~~~
eropple
A flag day on a bytecode format is "hating users"? It's a Python 3 split? Come
_on_ now. Heck, I can't come up with anything (and I've been thinking about
this a lot for a few weeks, as I spend more personal time in C# and getting
stuff done quickly that's kind of a pain in Java) that'd prevent automatic
translation of pre-flag bytecode to an equivalent matching the old code's
intent. If a jar has a pre-flag bytecode format, then rewrite to treat those
parameters at runtime as T => Object and transparently box value types that
are supplied for T. The pre-flag jar still contains the necessary information
for the compiler to throw a rod if generic constraints are violated. (You
could even experiment with more restrictive runtime constraints, but I haven't
thought through the implications thereof.)

But you know? If it takes laggards three years instead of the usual two to
jump from Java 9 to Java 10, I don't care. I shouldn't care, because I'm not
them. Oracle might. They can do that. But Oracle doesn't want my business if
they do to my detriment, and the more time I spend outside the JVM the more
annoyed I am by their self-imposed limitations. Microsoft seems like they
wouldn't mind my business, though, which is faintly astonishing. I'm happy
giving it to them if they're going to provide a better product. (I'm reserving
judgment until we see their Linux and OS X ports of their CLR, but I'm high on
it.)

And if you're seriously going to get riled up about "laggards", I hope you
never take an economics class, because they think words mean things and I do
too.

~~~
skybrian
Yes, you're probably right that they don't care about your business. Oracle's
actual customers are large businesses running hundreds of millions of lines of
code and they probably don't understand all of it. They probably care a lot
about preserving their existing investment. If they decide to put off
upgrading to the latest VM, Oracle can't sell them stuff.

The point here is to have some empathy. There are other people in the world
with different priorities. You can't say whether a technical decision is good
or bad without understanding what they're trying to do.

~~~
coldtea
> _Yes, you 're probably right that they don't care about your business.
> Oracle's actual customers are large businesses running hundreds of millions
> of lines of code and they probably don't understand all of it._

That was true for SGI, HP, DEC, SUN etc at some point too. See how the ended
when they didn't adapt?

SUN could still be alive and be pioneering all this cloud and web programming
in 2014...

They could have created something like Heroku (or lower level like AWS), they
could have added some flexible Rubu/Python Django/Rails like option for the
JVM (instead relying on third party ho-hum small attempts). They could have
pioneered the big data space.

Instead the insisted on Java for everything, and kept it as stale as they
could. This is were it got them...

~~~
skybrian
They did try. Sun had all sorts of innovative projects that didn't work out
(such as JavaFX), but they've been forgotten. Java on the server is what
remains. It may not be flashy, but it's a survivor (still around even after
Sun is dead) and it's likely to last as long as Fortran and COBOL.

It's only in the early adopter community that survival doesn't seem to count
for anything.

