Musings on JDK development

  • Java
    June 15, 2010

Syntax Sin Tax

In various forums, recent discussion about Project Lambda have commented on, and often noted in dismay, the current syntax for lambda expressions in the initial prototype.
"Don't panic!" is advice as valid for work on language evolution as on any other endeavor.
Since syntax is the easiest aspect of a language change to form an opinion on, it is the aspect of language changes most susceptible to bikeshedding.
While syntax is an important component of language changes, it is far from the only important component; the semantics matter too!
Fixation on the syntax of a feature early in its development is premature and counterproductive.
Having a prototype to gain actual experience with the feature is more valuable than continued informed analysis and commentary without working code.
I believe this diagram included in a talk on the Project Coin language change process holds for language changes in Java more generally:

While proposing and commenting can be helpful, the effort required to produce a prototype is disproportionally beneficial and the incremental effort using the prototype has even higher leverage. Experience trumps speculation.
And not all efforts lead to positive results; complaining and obstructing alone are rarely helpful contributions.

Just the engineering needed to fully deliver a language changes involves many coordinated deliverables even without including documentation, samples and user guides.
A consequence of an open style of development is that changes are pushed early, even if not often, and early changes imply the full fit and finish of a final product will of necessity not be present from the beginning.
Long digressions on small issues, syntactical or otherwise, are a distraction from the other work that needs to get done.

True participation in a project means participating in the work of the project.
The work of a language change involves much more than just discussing syntax.
Once a prototype exists, the most helpful contribution is to use the prototype and report experiences using it.

Join the discussion

Comments ( 10 )
  • Terry Wednesday, June 16, 2010

    It's good that people have pointed out that the syntax is ugly. I firmly believe that software is design and therefore that aesthetics matter. Giving feedback that something is looking terrible is quite appropriate in the prototype stage.

  • Neil Wednesday, June 16, 2010

    I agree with Terry. People will be more eager to participate in the project if they're excited about eventually using closures in their own code. When they look at the syntax and see how bad it is, the excitement of using closures dissipates, and they lose interest in the project. If you want to get more people involved in closures, you should modify the syntax to get them excited. I agree that in the ideal world this would not be necessary, but we don't live in the ideal world.

  • Paul Wednesday, June 16, 2010

    Joe, your concerns remain in the theoretical, not the concrete. People will rarely contribute to a project where their criticisms are seen as "complaining and obstructing". Ask yourself would you want to join that kind of development effort? If simple observations are so casually grouped as "complaining", rarely will observers become volunteers and put effort into the prototype.

    The syntax is horrendously ugly and yet no one in Oracle has admitted to that -- if they believe that at all. Instead, the general response is "the syntax is easy to change; please ignore it for now". Why? It's the biggest bullseye in sight. Neil and Terry are correct. Developers see an ugly syntax, developers see their first observations ignored, and interest in Closures tank.

  • Jesse Kuhnert Wednesday, June 16, 2010

    I think you guys missed the point entirely, they are most definitely saying that opinions shared about known issues which add no value to development efforts because resources aren't currently evaluating those known issues is pointless and disruptive.

    All you guys are saying is "well, yes it is! all must listen". Just don't participate in language development lists if you get easily upset by unfinished products. Like any other software.

    Maybe they should change the syntax to be something really outlandish like \^param value\^ for method invocations so people get the point. Or just kick disruptive people off the lists after a couple gentle warnings, as would be done in most development lists where user input is not really desired.

  • Neil Wednesday, June 16, 2010

    Jesse, I think we understand that point. The problem is that Joe seems to want more people to comment on the semantic issues, but he doesn't seem to realize that many potential participants are so turned off by the syntax that they won't do so. I'd bet a pretty large sum of money that Joe's blog entry here isn't going to cut down on the number of people complaining about the syntax. The only way to cut down on those complaints is to improve the syntax.

    I also think it's a mistake to downplay the importance of the syntax here. In a way, one could argue that syntax is effectively the entire point of adding closures to the language. After all, closures don't let us do anything that we couldn't do before -- they just let us do it with less typing, less boilerplate. One of the key things that people really want out of adding closures to the language is to make bits of code smaller, prettier, and easier to understand, and syntax is critical here. I think we're going to want to finalize the syntax sooner rather than later, to solicit as many suggestions for improvement as possible while it's still possible to make changes.

  • Jesse Kuhnert Wednesday, June 16, 2010


    If you truly are talking only syntax and not functionality, then I present to you http://www.antlr.org/grammar/list.

    People that don't understand this difference are likely not going to have a lot of meaningful syntax input in the long run anyway...there's always an off chance that the one brilliant comment that makes it all come together really is out there pouting and not sharing but ....

  • Joe Darcy Wednesday, June 16, 2010

    @Terry, @Neil, and @Paul,

    As in other matters, syntactical beauty is in the eye of the beholder. New syntax will most likely look "alien" at first because as something new, it is also something unfamiliar.

    Looking at a syntax for a few minutes and sending in a note saying "Boy, this is ugly" does very little to add to the discourse around developing the language change.

    People are not obliged to participate in Project Lambda, Project Coin, or other in-progress language development efforts. If people do choose to participate, there are less superficial and more helpful comments to provide beyond "I don't like this."

    The most effective ways to cut down on complaints are to be less open about in-progress work and cut down on the number of potential venues to voice a complaint!

    Java 1.0 was Turing complete so strictly speaking no subsequent language changes were needed for raw expressiveness, but of course other criteria about the structure of code needed to express computations have been and continue to be taken into account when evolving the language.

  • Gili Wednesday, June 16, 2010

    Jesse, Joe,

    Your replies speak volumes.

    When pitching a product to a customer (in case you haven't noticed, you are still pitching) one should focus on the user interface before writing a single line of code.

    You can design the most incredible closure implementation in the whole world, if you treat the syntax as an afterthought you will have a community size of exactly zero.

    Focus on the syntax first and grow a captivated community. "The medium is the message".

  • Joe Darcy Wednesday, June 16, 2010


    This is not yet a product, it is an in-progress development effort.

    There is a difference between treating syntax as an afterthought and treating syntax as the only aspect of the change which matters. Either extreme is ill-advised and Project Lambda is not committing either mistake.

  • Neil Friday, June 18, 2010

    It's difficult to comment on semantic issues without seeing the entire plan. I think one of the problems here is that no one outside Oracle knows what features Oracle intends to support via closures -- things like http://www.jroller.com/scolebourne/entry/exception_transparency_and_lone_throws just kind of pop out of nowhere. If Oracle were to publish a full plan, including all of the closure-related changes they intend to make, and also outlining the syntax, that would probably shut up the syntax complainers and also get you more useful feedback on the semantics.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.