Something simpler?

[Reinier Zwitserloot]

On Fri, Mar 19, 2010 at 6:20 AM, Knox, Liam <Liam.Knox at morganstanley.com>wrote:

>  1. Look at wild cards and Generics and say they are easy to
> read/understand. They do add complexity
>

The complexity added by generics is inherent in the code. Since 1.5 it has
been made visible. When you see a List you need to know what you can put in
it, and what you can expect when you take objects out of it. Making
complexities visible makes things easier to understand and less complex to
read.

The difference between Levart Brackets and Reinhold Strawman is a completely
different story. The semantic complexity is the same, it's just a matter of
what's easier to look at.


>
> 2. Look at this
>
> [:int] two = (:2);
>
> assert two[] == 2;
>
> a. is it easy to understand?
>

Yes, once you've been told you're looking at closures. As I've also said ad
nauseam, especially the invocation (assert two[] == 2) would look better to
me as assert two.() == 2. You're also asking entirely the wrong question.
The right question is:

Is it eas*IER* to understand than:

#int() two = ()(2);

assert two.() == 2;

and the answer to me is clearly: Just as difficult, though the one with the
brackets is easier to read at-a-glance once you're familiar with the
concept. What would possibly cause someone to jump to the conclusion that
the empty pair of parens in front of the (2) is a parameter listing? I grant
you that {} will most likely suggest 'code block', but parens are used in
far too many places to suggest parens list.


> b. Does it look like Java ?
>

No more, and no less, than Reinhold Strawman closures. Which is mostly to
say: Less. The following WOULD 'look more like Java' to me, though I'll just
call it without the euphemisms: I have a personal preference for:

public interface Producer<T> {
    T produce();
}

Producer<Integer> two = (:2);
assert two.produce() == 2;



>
> 3. I did not say I was very concerned if  () was used, do not invent what I
> said. I said I was concerned with introducing ambiguity.
> Of course I know where else () is used, that is not the point.
>

You defended the use of () as not introducing ambiguity, and/or being
intuitive, and I pointed out that the idea that () is intuitive doesn't
work, because its already used everywhere and thus has become mostly
meaningless.


> If you are expressing blocks of behavior use { } as it is most familiar, if
> you are expressing params use (), if you want to express something else, use
> something else
>

The Levart Brackets proposal does use {}. Its alternative colon-based syntax
for param usage is specifically as a response to concerns about readability,
and to differentiate function types from the closures themselves, something
Reinhold Strawman is bad at.


>
> Basically I am coming from a perspective of someone who uses this language
> everyday for year on end
>

Just like me then.


> Given that I am still using this language and not another one probably says
> a lot of what a success Java is and paramount to this
> succes is its simplicity.
>

Sure. Please define Simplicity. I'd say being able to easily differentiate
between a function type and a closure is part of whatever definition you end
up with. So is being able to read intent of code at a glance which is harder
when a parade of parentheses is involved. Brains are bad at matching parens.


>
> I don't want Java++
>

Brackets instead of parens means Java turned into Java++? That feels like
overstating the case just a tad.


>
>
Based on this debate clearly Gosling was right (or lucky) not to add them
> from the start.
>

Where is this conclusion coming from? If java used [] for closures from the
start you wouldn't be making this complaint, and this mailing list wouldn't
be bending itself backwards to attempt to come up with some sort of syntax
that is readable, somewhat intuitive, and doesn't conflict with existing
java syntax. That last one wouldn't have been a concern if it had been in
java from day 1.