Weblogs Forum - Will Closures Make Java Less Verbose?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Will Closures Make Java Less Verbose?

70 replies on 5 pages. Most recent reply: Apr 10, 2008 9:09 AM by Mark Thornton

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 70 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Dave Webb

Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 30, 2008 11:49 AM

From a developer's point of view, Scala has demonstrated too many possibilities for a language on the JVM, both features and philosophy, to want to restrict a new language to just Java-done-right.

Java3K sounds like an attempt to settle old frustrations with a language we used to love, and will just muddy the waters.

Any serious attempt at developing a new (static) language for the JVM has got to use Scala as its benchmark rather than Java.

David Rosenstrauch

Posts: 3
Nickname: darose
Registered: Sep, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 8:41 AM

> <p>Would it make sense to create a "Java 3K"
> (playing off of <a class="reference"
> href="http://www.artima.com/weblogs/viewpost.jsp?thread=196
> 889">Python 3000</a>, the name given by Guido Van Rossum
> to the once far-off, backwards-incompatible, fixed-up
> version of Python which is now going to appear sometime
> later this year)? A new version of Java that still runs on
> the JVM and has syntactic similarity with old Java, but is
> not hobbled with any kind of backward compatibility
> issues, so it can have real generics, closures, get rid of
> primitives, etc. If a company didn't want to move to Java
> 3K -- the same company that probably hasn't upgraded to
> Java 5 -- then it continues working with what it already
> has. But programmers who are being held back by the old
> issues and old bad decisions made in old Java can easily
> move forward into Java 3K, with only a small learning
> curve and virtually no productivity shortfall.</p>
> <p>What do you think?</p>

I think that's a very good idea. Generics got botched because Sun refused to sacrifice backwards compatibility.

But there's two simple facts here:

1) no designer can anticipate everything right up front, and
2) if you want to add new features (without making them a complete mess), then you're going to have to break some backwards compatibility at some point

I think that what Sun should do is make a JDK3000 that addresses some of the key issues (e.g., generics, closures, methods as first-class objects, etc.). And as far as backwards compatibility, they should make it so that old Java code will compile to and old java class files will run on the JDK3000 VM (i.e., in some sort of compaitibility mode), but that there's no need for new Java source code to be compatible with old Java class file formats, like the way generics are. (i.e., typing info gets stripped from classes so that they can run on old VM's)

Time to break with backwards compatibility. The language needs to move forward - or other language will move forward instead of it.

Jesse Kuhnert

Posts: 24
Nickname: jkuhnert
Registered: Aug, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 10:12 AM

Thought this was conveniently relevant:

http://video.google.com/videoplay?docid=-8860158196198824415&q=guy+steele&total=977&start=0&num=10&so=0&type=search&plindex=0. Growing a Language, Gut Steele.

Jesse Williamson

Posts: 9
Nickname: chardan
Registered: Dec, 2005

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 10:25 AM

Instead of "Java 3k", how about a real networked open machine and perhaps set of libraries that go with it which are constructed such that we can use whatever we like with it?

Casper Bang

Posts: 12
Nickname: mrmorris
Registered: Nov, 2007

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 11:24 AM

> Thought this was conveniently relevant:

For all the language experts Sun has employed over the years (incl. Guy Steele), it's funny they have failed so miserable at growing the language in contrast to how Anders Hejlsberg does it. I.e. letting methods be non-virtual by default to reduce risk of accidental override, using contextual keywords to allow new ones, extension methods to pseudo-extend API's etc.

> Instead of "Java 3k", how about a real networked open machine and perhaps set of libraries that go with it which are constructed such that we can use whatever we like with it?

Something similar was proposed the other day, as a merge between the JVM and Mono: http://cgwalters.livejournal.com/14913.html

Andres Almiray

Posts: 2
Nickname: aalmiray
Registered: Jul, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 12:48 PM

> To me, J3K would be:
> - drop primitives
> - make operators become methods
> - make classes become real objects (enabling
> meta-objects)
> - make methods become first-class members
> - shift control structures to API solutions
> - keep Java "look and feel"
> - keep interoperability with JVM-based languages

Hmmm seems like you are expecting something like Groovy (about time somebody else mentioned it :-P)

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 1:07 PM

I'm o.k. with a non-backwards-compatable Java, so long as all the parts are updated. For example, Swing still uses Vectors in many places instead of generified Lists. As Eli mentioned, the 3rd party software is a huge issue. Many of the Apache libraries I'm using do use Lists but they aren't generified.

For the record, I remain unsold on the huge claimed benefits for closures. If you are only writing them once in a while, then the extra verbosity of an inner class is tolerable as a tradeoff for a possibly confusing new language feature. (That, by definition, you aren't using much!)

If you are using closure styles a LOT, then writing them in a quick-and-concise inner class-like "here it is once" is also wrong, cause it's a maintenance nightmare. If you are doing a lot of summing or wordcounting in a fold, write it as a separate class. That way when the rules change to handle complex numbers or Mandarin, it's one place to fix, not 1000s.

Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 1:08 PM

It's hard for me to imagine that someone could look at code in Ruby or Python and then look at the equivalent code in Java and say that the verbosity makes the code more readable. I've written the same for loop hundreds of times to turn one list into another list (i.e. "map") or shove a list into a map or find matching elements of a list, and there's just no way to do it nicely. We write claims systems, so say I have a list of claims I want to partition by user. I might do that like:

Map<User, List<Claim>> claimsByUser = new HashMap<User, List<Claim>>();
for (Claim claim : someListOfClaims) {
  List<Claim> claims = someListOfClaims.get(claim.getUser());
  if (claims == null) {
    claims = new ArrayList<Claim>();
    claimsByUser.put(claim.getUser(), claims);
  }
  claimsByUser.put(claim.getUser())
}

Ugh. If I was feeling like making the code re-usable, I could get crazy and put it in some reusable function that takes an anonymous inner class:

Map<User, List<Claim>> claimsByUser = ListUtils.partition(someListOfClaims, new Partitioner<Claim, User>() {
  public User partition(Claim c) {
    return c.getUser();
  }
});

That's maybe a little clearer and it's marginally less code, but still pretty verbose. I’d much rather write something like:

var claimsByUser = someListOfClaims.partition(\ claim -> claim.User)

To me that's a huge gain in clarity, even though the type declarations are no longer explicit and there's a closure involved. The only possible point of confusion is if you don't know what "partition" does, but that's what javadoc is for (or just read the implementation) and hardly seems like a reasonable argument (since then it would be an argument against any sort of method decomposition).

In the common Java case (just a for loop) the code is much more opaque, since it looks like every other for loop in Java, and you have to read it carefully to realize that it's partitioning a list. It just takes more work to understand, not to mention more work to code (and as a result is more error-prone to code). The inner-class approach is cleaner, but still pretty ugly compared to the closure approach.

Java needs both closures and type inference badly. It needed type inference before 1.5, but generics really pushed it over the edge in terms of verbosity.

It doesn't, however, need a version of closures that includes crazy scoping rules, return semantics, and exception handling, so I hope something other than BGGA wins out. I don't hold out much hope for type inference, given the level of resistance the community seems to have to it, but anyone who thinks it makes the code clearer to litter it with unnecessary type declarations should try programming in a type-inferred language for a while and see if that's really the case. In my experience it's a huge, huge win for code conciseness and flexibility.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 2:01 PM

> > * There is a suicidal commitment to non-local returns.
>
> Depending on the proposal you are talking about. The only
> one having non-local returns is BGGA, because it focuses
> on the biggest hammer available to hit every nail
> existing.

Yeah, that's a good point. I'm under the perhaps mistaken view that Gafter gets what Gafter wants, and his proposal will win out. I certainly hope one of the less insane proposals wins out, but I don't have high hopes.

> > * There is a comical commitment to "user defined
> control
> > structures" which are perhaps the least useful, er, use
> of
> > closures.
>
> I thought, you were arguing facts on not making
> Java less verbose. Control abstraction definitely reduces
> verbosity.

Another good point. I'm switching modes midway into a criticism of the overall problem that the java guys are taking. I should have been clearer: control abstraction can reduce verbosity somewhat, but at what I consider too large a complexity cost. That's a matter of taste, of course.

> > All but #2 are addressable right now in the "consensus"
> > (ha!) closure proposal, but they won't be addressed
> > because, well, because.
>
> Well, the "consensus" is, that we all want closures and
> see a huge benefit for Java in having them. It's not about
> a particular proposal or a final set of semantics or
> syntax. If you have ideas, concerns, requirements, etc. on
> closures, join the supporters and/or propose alternatives.

Well, you certainly are beating the sh*t out of me here. You are right again. It's much easier to just sit back and take pot-shots at the proposals rather than do something proactive about it. In my defense, we are probably going to be releasing our internal JVM-based language in the next year, and that language has what I consider nice, tight typesafe closures in it. (I work at the same company as that Alan Keefer kid.)

Thanks for keeping me honest.

Cheers,
Carson

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 2:35 PM

How about

Map<User, List<Claim>> claimsByUser = ListUtils.partition(someListOfClaims, Claim.USER);

and, inside Claim.java, put the "little inner class".


public static final CLAIM = new Partitioner<Claim, User> () {
   public User partition() {
     return this.getUser();
   }
 });

Suddenly, most things are only there once, the 100s of times you make this call are just one line of code, and the parts (arguably) are in good places. When somebody changes Claim to use getMyNewImprovedUser(), it's in one place, not 1000s.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 2:37 PM

The couple of typos in my post are left as an exercise to the reader. :-)

Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 2:49 PM

> How about
>
>

Map<User, List<Claim>> claimsByUser =
> ListUtils.partition(someListOfClaims, Claim.USER);
>

>
> and, inside Claim.java, put the "little inner class".
>
>


> public static final CLAIM = new Partitioner<Claim, User>
> () {
>    public User partition() {
>      return this.getUser();
>    }
>  });

>
> Suddenly, most things are only there once, the 100s of
> times you make this call are just one line of code, and
> the parts (arguably) are in good places. When somebody
> changes Claim to use getMyNewImprovedUser(), it's in one
> place, not 1000s.

But what if I'm not writing that same line of code 100 or 1000 times? What I'm writing is similar-looking for loops 100 or 1000 times, but each exact loop I'm probably writing just once.

It seems like you're saying, "It's okay for code to be verbose, since you just hide the verbosity somewhere reusable. And that's better anyway, because then you have reusable code." But at some point you stop running out of stuff that's reusable and decomposable, and at that point if I end up with 50 lines of code instead of 200 lines of code I'll be happier. Sprinkling it across different files or hiding it in method calls doesn't make that code go away. Sure, it's a small tax, but little things add up over time.

There are plenty of ways to reuse code in Java, and I'm all for reducing redundancy, decompsing things, etc. So what you say might be appropriate for a method that's really used a number of times, but it's total overkill for every single time I want to do a one-off data structure manipulation. And one of the problems with Java is that it forces you to do these heavy-weight things to solve simple problems. Solving complex problems complexly? It works fine. Solving simple problems simply? It doesn't work so well.

In other words, for any given problem, the smallest reasonable Java program that can solve a problem is probably 3-5x larger (at least) than the smallest reasonable Python program that can solve the problem, and the Python program is undoubtedly easier to read and modify. And that's not just if you try to make the Python code incomprehensibly small. That's not a good thing for Java, and it doesn't have to be that way; closures and type inference would go a long ways towards making the Java programs look more like Python programs, and without losing any of the static typing that everyone relies on with Java.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 4:27 PM

If you are using your business classes over and over to provide various keys for this mapping, how about adding a method to them

getKeyForMapping(String whichKey);

(which probably just calls a Map or Properties to get the value, so it's not much extra work)

then your call would look like

ListUtils.partition(someListOfClaims, "user");

(where "user" should be in a constant or an Enum.)

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 4:50 PM

> ListUtils.partition(someListOfClaims, "user");
>
> (where "user" should be in a constant or an Enum.)

Are you serious? You really prefer that to:


  var usersToClaims = somListOfClaims.partition( \ c -> c.User )

where you don't have to go to any effort of creating a new one-off method (or enum!), you get code completion, you get type safety, you don't have to annotate any types and you don't have to work out exactly what the return type of the method is since type-inferencing took care of it for you?

The type-inferred closure-based approach just seems obviously, self-evidently, sand-poundingly better to me that I'm not sure you are giving it a chance to roll around in your head.

Cheers,
Carson

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Will Closures Make Java Less Verbose?

Posted: Mar 31, 2008 8:00 PM

If "user" is an enum you'd get code completion and type safety.

If not, there's no effort making it an enum.

Not having to work out the return type is irrelevant to the closure argument. (And the IDE will do it) If you don't want to work out the type, feel free to go

Map someMapIDontKnow = ListUtils.blah.blah.

It's not fair to complain that generics are only partly implemented, then to complain that they are implemented. :-)

> The type-inferred closure-based approach just seems
> obviously, self-evidently, sand-poundingly better to me
> that I'm not sure you are giving it a chance to roll
> around in your head.

In the case where you are pulling methods at random from objects to pass to the closure, yes, closures are easier. I guess I'm really arguing that making it really easy to pass any method you feel like to a closure seems dangerous and a maintenance nightmare. Cause all too often that "trivial method call" becomes "we're supporting Chinese and Polar coordinates in the next version".

Flat View: This topic has 70 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic