Project Lambda: Java Language Specification draft

[Reinier Zwitserloot]

We're veering rather wildly off the path here, with comments that have very
little to do with performance concerns we should keep in mind whilst
designing language features. I'll keep it short, and inline.



On Mon, Jan 25, 2010 at 7:29 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:
>
> They designed [swing], apparently with the assumption that polymorphism,
> stack frames, code size, extra indirection of some design patterns, etc. are
> all "nickel-and-dime issues" that wouldn't matter.
>

You fantastically misunderstand the problems with the swing API. The
complaints are about the _API_ - the way you build apps with it. Not about
performance. Netbeans performs just fine and the API didn't change one whit.
Yes, swing apps used to be slow. They fixed it, without removing any of the
nickel and dime stuff. It would be annoying and complicated, from an API
point of view, to state that list literals come in lots of varieties and
have all these options. It would be far simpler if a list literal is always
the same immutable structure, and if you need more/different features, you
create a new list initialized with the list literal.

Swing is actually an example of why your performance crusade is in fact
wrong: It proves that high-level optimizations are the only ones that
matter, and it also proves that making API simple and eliminate as many
options and complications as possible is a good thing.


>  my NetBeans compiles pretty fast too, indeed both compilers are now
> I/O-constrained on any recent machine/JVM, so this is not anymore a good
> case study.
>

So, javac vs. ecj is no longer a good case study? Huh? No, it _IS_ a good
case study, it is serious anecdotal avidence that that micro-optimization,
which is what ecj has done, does not help performance any, and instead makes
a dog of a code base that is such a drag on maintainability and flexiblity
that eclipse is legendary for lagging behind new java features so much.

I'm still waiting on even one case study on your end that this micro
optimization bullpuckey is worth screwing up language features for.


>
> You invite me to a losing "proof" game
>

I wouldn't invite you to it if I wasn't fairly certain you'd lose the game.
The point is - your argument should not be used to complicate the list
literals proposal, and I've given several cases which prove that micro
optimization is not a major concern to back up my sentiments. You, on the
other hand, keeping saying, in elaborate overtures, "No, no, they are
important! Trust me, even though what I say goes against all common
knowledge and I have no proof or even a use case to back up what I say!". If
cannot speak for those implementing the list literals or for the rest of
coin-dev, so on behalf of myself: This "I've been in this business for
years" hand waving isn't convincing me at all. Prove that
micro-optimizations are worth making this new feature complex for.


 Yeah that would add yet special case to learn (if you care for precise
> behavior), but the current spec is already counter-intuitive because Java
> developers quickly learn that indexed iteration of ArrayList and friends is
> better than using an Iterator (and won't ever throw CCE!), then comes
> enhanced-for and breaks this intuition.
>

indexed iteration across an arraylist is better than using an iterator? I
beg your pardon?

Iterators don't HAVE to be fail-fast. There's extra logic in ArrayList and
friends to make them fail-fast. someone back then (correctly, but a full
discussion is beyond the scope of this thread) decided that fail-fast is
worth it. If you want to turn this around and say that fail-fast is actively
harmful compared to the standard 'who knows what's going to happen'
behaviour of indexed access through an AL, that's your right, but you
certainly can't do it by just saying that "It's better!" without backing
this up!