• Mike just posted a
    very thorough analysis of Groovy’s syntactic flaws.  Here are a few
    comments on some of the points he made:

    In general, now that I’ve looked into the Parser code in depth, I am deeply
    distressed by how often the parser looks at newlines as being semantically
    meaningful. To put this in the strongest possible terms, WHITESPACE
    SENSITIVITY IS JUST PLAIN WRONG IN A LANGUAGE LIKE GROOVY    .

    I think the problem is not exactly there.  The rule of thumb is: 
    if spaces are not semantically meaningful, then neither tabs nor newlines should
    be.  Groovy is clearly violating this principle, and this needs to be
    fixed, but I think that instead of replacing the existing closure syntax with
    the one Mike’s proposing (sorry Mike, I’m still not crazy about the "closure"
    keyword), it would be better to simply fix the parser so that closures can
    remain as they are and be absolutely space/newline/tab neutral.  The
    resulting grammar will most likely not be LALR(1), but that’s a problem for
    James and his fellow developers, not users…
     

  • I like the way Python makes spaces meaningful, but I am afraid that in the
    presence of closures, such indentation is doomed to fail.
     
  • I also like the idea of doing away with parentheses altogether. 
    It looks quite alien the first time you do it, but it grows on you very fast. 
    After all, who cares if "person.firstName" refers to a field or to a method
    call, all you know is that it returns a string representing the first name.

    That being said, if you go that way, the syntax for invoking methods with
    parameters become harder to parse when you read the code, especially in the
    presence of named parameters, although once again, this is something you might
    eventually get used to as well.

My overall feeling on all these issues is that when it comes to writing code, the
developer’s options should
be limited to spaces, newlines and tabs.  In other words, the language
should let me format my code that way I want it, but there should be just one
way to write syntactically correct statements.  Therefore, Groovy should:

  • Impose semi-colons everywhere or not impose them at all.
  • Require parentheses for method calls everywhere or never require them.

Most of the flaws depicted in Mike’s posting are nothing more than signs of a
very young language.  James and his team are experimenting with various
ideas but haven’t had the time to really consider all the syntactic and semantic
implications of their ideas, which further obviates the necessity of a JSR to
fix these problems.

It will be the
Experts Group responsibility to keep the language in check, both syntactically
and semantically, and make sure that Java developers can adjust to it very
quickly while still retaining the power that Ruby and its siblings offer to its
community.