"Bleah, Layers are too complicated!" (was: Updated State of the Specialization)

Brian Goetz brian.goetz at oracle.com
Sun Dec 21 16:57:03 UTC 2014


I can understand why everyone is inclined to jump all over layers as 
being "too complicated"; we have our own concerns there too, which I 
think we've been honest about.  But, you're all getting ahead of 
yourselves; it feels like you're having a collective panic attack of 
"OMG, they're going to kill Java with complexity, so I'd better freak 
out."

So everyone ... relax.

Right now, we're still *figuring out the problems* (which includes 
separating the real problems from the perceived ones).  The one thing I 
know is that the final solution will almost certainly look very 
different.  (Everyone says they want us to work more openly, rather than 
emerging from our cave with the final answer -- but you have to do your 
part by showing some awareness that what we're sharing is work-in-progress.)

We've only thought about these issues for maybe a thousand hours so far; 
that's not enough to get a good answer to hard problems like this.  So 
*of course* the solutions we've got so far are half-baked.  How could 
they be anything else?

Until we fully understand the problems, we are going to focus on the 
theoretical characteristics of the possible solution, how well it solves 
the problem, and how the solutions fit in with how the language actually 
works (i.e., the type system, overload selection, method dispatch, etc). 
  The fact that it looms too large in the user model or the syntax is 
weird or has a lot of surface for what feels like corner cases can't be 
our top priority now; focusing on the surface aspects distracts from 
figuring out whether we're even on the right track or not.

Now, it's common that the solutions one ends up with after the first or 
second or third round is still more complicated than you'd like, so then 
begins the agonizing slow process of peeling back perceived requirements 
in order to simplify how the solutions fit into the user perception of 
the language.  It seems that people want to "help" by jumping right to 
that end stage by saying "this problem isn't important to solve".  But 
unexamined opinions of which problems can be punted on is not really 
that helpful to us.

The thoughts we're sharing are very much work in progress.  Please 
engage accordingly; at this stage, constructive help looks like 
generating better understanding of the problems.




More information about the valhalla-dev mailing list