Something simpler?

[Jesse Kuhnert]

I agree that the [] looks ugly, don't have the stamina to read these
long-winded and kind of annoying emails all the time though.

On Fri, Mar 19, 2010 at 9:34 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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.
>
>