Bruce Chapman's Blog

Luddites - Watch Your Back

Neal Gafter's latest blog on closures has attracted two or three comments from people wanting to object to generics, and a number of other conservative commenters voicing an objection to closures. Josh's JavaPolis presentation makes a valid point that these opinions cannot be ignored.

I have invested some time getting my head around some (but not all) of the closures proposals. I don't know whether I find that easier or harder than your average practitioner, but with a little effort I can now relatively easily read and comprehend most example code.

I have also invested some time getting my head around the early draft of JSR-308 and there are parts (like method receivers) of that which I just can't get my head around. Maybe I'm thick, or maybe the spec does not do a good job of explaining what is fundamentally a good idea, or maybe the idea is fundamentally wrong. I don't yet know.

What I do know is that closures is not the only language proposal out there that can make a java program look foreign to those who can't or won't put in the effort required to internalize them. JSR-308 makes closures look simple, and its a lot closer, in terms of the JSR lifecycle, to becoming a part of the java language specification.

To all those who are voicing opinions against language changes that make java more complex, have you read the JSR-308 early draft? And have you sent your comments to the expert group?

Comments

• @eirikma: There is no need to fear that universities switch to teaching dot net instead of Java because of the complexities of closures: They are already part of C# 3.0 (called "lambda expressions" there), together with many other language features (extension methods, expression trees, ...). I think the opponents of new language features should look over the rim of the Java coffee cup now and then...

  Posted by: scotty69 on December 19, 2007 at 02:17 AM

• I think that the current closure conflation of closures with custom iteration is dead wrong. I mean yes, we can implement map, filters and such as with closures, but also with other constructs with EASIER readability and LOCAL returns. Notably i'm pushing (like an ant) for list compreensions (or even better, phyton style generator expressions: http://www.python.org/dev/peps/pep-0289/)
  These, as they are "expressions" can not be passed into methods. A few of these for the primitive constructs map, filter, reduce and we could replace almost all of the closure spec by a CICE like method of function pointers. The only parts that couln't be simulated would be the parts that MAKE trouble, non-local returns, code blocks etc.

  And more importantly they are MUCH easier to read.

  Posted by: i30817 on December 18, 2007 at 05:31 PM

• Hey, I'm not a Luddite, I just want to keep Java simple enough so that universities don't switch to teaching dot net or visual basic. Besides, the suggested syntax IS butt-ugly (albeit very efficient for expressiveness per character, I admit that). Okay, maybe I am a Luddite then. But I still mean the proposals are not good enough.

  Posted by: eirikma on December 18, 2007 at 03:04 PM

• I think the comparison to C++ is apt. Standard C++ has become so complex that it is hard for the compiler writers to get compliant versions correct. While I know C++ very well most developers struggle to read C++ code written by others. Java developers who have been around a long time have noticed this and don't want their beloved Java falling into the same trap.

  I think some of the resistance you have mentioned isn't pure Luddism. It is the sneaking feeling from developers that language architects are complicating the language mostly for their intellectual amusement. Meanwhile more practical, but intellectually simpler, language extensions (such as switch by string literal) are usually dismissed from consideration - even though such behaviour must be implements in quite a few real-world systems I've worked on.

  So I'm not too find of closures, since their effect can be pretty much be acheived using existing means. As green-fields development is relatively rare and I'm usually extending someone else's Java cruft on a big system I've ended up a huge fan of Einstein's maxim, "As simple as possible, but no simpler". Not as exciting, but it gets things done.

  Ruling any changes out is absurd, but I think we should be relatively conservative about what we do change. No changes for things that can be done already, and no change for change's sake, eh?.

  Posted by: staubsaugernz on December 18, 2007 at 12:54 PM

• Method receiver annotations are good for extensions to the basic Java type system. For example, Ernst's "Javari" project adds a form of reference invariance checking, which is like a finer detailed version of C++'s "const". Just as there would be "const" methods in C++ to represent a const receiver, it's desirable to label the receiver of a method with a variety of other annotations.

  For example, you could imagine an extension to the type system which keeps track if a file has been opened or not, and that certain methods can only be invoked on open files, others can only be invoked on closed files, and still others can be applied to either. Without the semantic checking, this would just be a way to document the program. But the hope of the expanded annotation proposal is to allow third-party checkers and other lint-like tools to do the rest of the heavy lifting: All that they need now is a way to integrate with the language.

  You won't necessarily be able to "do more" with such an annotated program, but the whole purpose of type systems is to limit what you can do.

  Posted by: mshonle on December 17, 2007 at 03:41 PM

This work is licensed under a Creative Commons License.