Too terse and too alien?

[Mikael Grev]

Thanks Ruben, I feel the exact same way and has been going on and off if I was to say something given that almost all on this list seem to be very compiler focused, at least those who respond.

What won't be understood by the general (95%) developer is the reasons why syntax turned ugly/non-Java/whatever. They will all judge closures by the simplicity of the syntax, how "Java-like" it is, and do so swiftly with a few examples. And mind you, Java-like will mean different things to different people, which makes this all so complex.

As I think Oracle already know, things like

  myClosure.(1, 5) 

won't fly very well with the general developer. The reasoning behind the dot, that the name otherwise lives in the same name space as methods, is not understandable by most. And even for me it looks like a compiler purists way of reasoning. myClosure(1, 5) is the only way. It looks Java (my interpretation if it) and my IDE will color/font code it for me to distinguish it from a method call, which it isn't completely unrelated to anyway.

I also believe that 

   myMethod(Runnable r)

should be invoked

   myMethod( #{System.out.pringln("") } );

and that the parsing should be lenient with all the missing parenthesis and semi colon stuff, if at all possible without creating ambiguities. Same there, I understand the reasoning why someone wants to keep the parsing clean but, again, that is the parser coder's problem and I would happily give the extra resources for it if I were at Oracle. All in the very important name of shaping how this will be received in the blogosphere.

Also,

#(int i) (i * i)

should be written

#(int i) {i * i}

just like a normal closure. There's no need to make it special and use parenthesis just because it is only one expression in there. That's for the parser/compiler to figure out. Less to learn, easier for the user. And he can write it 

#(int i) {return i * i} 
 or even
#(int i) {return i * i;}

without making it look like something else entirely.

I don't in any way say that the syntax simplifications above is the ultimate answer, or even better. But anyone that don't understand why those kind of user-space simplifications are important shouldn't have a final call on the syntax IMO.

KISS, and let the compiler/parser do the heavy lifting.

Cheers,
Mikael



On Jun 1, 2010, at 19:59 PM, Ruben Badaró wrote:

> I believe that aesthetics, with their effect on perception and emotional
> response are being a bit ignored during this process. We're (mostly) all
> engineers here and it's normal for functional goals to supersede other less
> objective concerns.
> 
> Regarding the feel of Java, I would say there is a generalized,
> almost unintelligible feeling of what looks like Java and what doesn't. This
> is a similar notion to what the Python community calls "being pythonic".
> While most people in this case don't really know what it should look like,
> the feedback from outside the mailing list appears to point that a number of
> people (in my personal sampled universe, a lot of people) don't think the
> proposal feels like Java.
> 
> In my opinion, the group should consider this feedback very seriously.
> 
> 
> Best Regards,
> 
> Ruben Badaró
> 
> 
> On Tue, Jun 1, 2010 at 6:36 PM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
> 
>> Though I know I'm now expressing a different opinion than I was
>> originally (thanks to Alex for pointing it out), a lot of this is
>> indeed artistic / creative and not strictly measurable in the
>> traditional sense. If we did things that way we'd just slap some blue
>> colors on it like google and call it a day right? (not trying to pick
>> on google too much, but well ...)
>> 
>> Much like traditional art, not all opinions are created equal. Not
>> saying that anyone is right / wrong, just that I'd tend to trust the
>> most knowledgeable to brainstorm and find something that feels the
>> most natural above anything else. (not that alternative syntax options
>> probably aren't welcome as long as they fit all the same functional
>> goals)
>> 
>> On Tue, Jun 1, 2010 at 11:08 AM, Reinier Zwitserloot
>> <reinier at zwitserloot.com> wrote:
>> <snipped/>
>>> 
>>> 
>> 
>>