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.
|
|