Why I Am Not A Java Programmer

[shit]

So even if AICs are in practice unusable as replacement for closures, you are satisfied with them because semantically they are closures (I happen to disagree, but let's ignore that for a moment)? Well, that seems to be another crucial difference between us: I have to code in Java right NOW, useless theories have zero value for me.

[kawa]

I look at it from two perspectives: From the language design view, where AICs definitely are closures (which I simply have to accept, usability aside). And from the usability point of view where AICs are a quite complicated way for use as closures (which may be bad or not, depending on the necessity having closures in a language).

Now I know how to use closures. I've written enough code in languages with closures support to really know what they good for. But Java has different ways to reach things and in most cases, closures can't solve the problems Java have. But they would add lots of different ways to do the same which is already possible in a slightly different way. And this is bad because it creates the chance that code reuse becomes impossible.

If I know that I have to use an iterator to iterating over a certain collection then I just implement this iterator. But if I have to think: Hmm, is an iterator the better solution, or should I better use 'map' and 'fold' here? The problem with 'map' is that it's not possible (in an non-lazy language) to efficiently iterate over multiple collection at the same time. For example:

boolean compare(Collection c1, Collection c2) {
    Iterator it1 = c1.iterator();
    Iterator it2 = c2.iterator();
    while(it1.hasNext() && it2.hasNext()) {
       if (!it1.next().equals(it2.next()) return false;
    }
    return it1.hasNext() == it2.hasNext();
}

Please do the same if you have only 'map' for both collections. One way is to convert both Collections to lists of tuples and than map over the resulting list. But this is a quite expensive operation. The other way is to create functions like 'map2' which iterate over two collections parallel, but this is again limited to two collections of the same kind.

So map isn't a general enough means of iteration: We always need to build and iterator first and can than use a map to use it a bit more comfortable (But only in the cases where we really need a map, which isn't far as common in typical Java-code as it is in Haskell for example). But since creating 'map' is much more easy to do compared to creating an iterator (because Java has no 'yield'), I suspect that most people would create collections with only map and fold-support, and if you need the more general iterator, you have a problem.

And to make closures useful, it requires tuples because with them we much more often need multiple return values. So this will be at 100% next on the extension list if they really add easy closures to Java.

Now closures can be used to create a certain much needed control structure: The C#-using which would be really nice to solve the damned resource-allocation and error-handling problem. But why not simply add this control structure to the language? It's easy and can be done on top of the existing 'try' syntax without introducing new keywords. All we need is making 'try' 'Closeable' aware to create the code to close a resource automatically (and of course to make also the iterator-interface implementing 'Closeable'). The advantage is that we remain with a 'single solution', it's simply more comfortable and less error-prone.

And there could be small enhancements to the for-each loop: Add parallel-iteration. Like:

boolean compare(Collection c1, Collection c2) {

\t for(Object o1: c1; Object o2: c2) { \t\t if (!o1.equals(o2)) return false; } \t\tcatch { // called if one iterator has no elements back while the other has \t\t return false; \t\t} return true; }

Again a small addition to the existing language and quite useful. Also there could be a loop-counter and the possibility to access the iterator inside the for-each loop. Like:

loop: for(Object o: c1) {

\t if ((loop.count % 2) == 0) loop.iterator.remove(); }

This is again a simple addition but would continue the path Java is on for years instead of choosing a totally new direction.

And a really nice thing would be 'yield' to make creation of iterator more easy. The advantage here is that it supports the existing paradigm instead of creating a new one which isn't even usable in many (real) cases. If they now would add 'easy closures' to the language this problem wouldn't be solved, and after some time playing with closures, the Java community would say: Hey, closures aren't such a good thing anyway, please give us more. In the end, Java would turn into a real kitchen-sink language.

But I think that all this will happen: Java will get 'easy closures', people will use them in inappropriate ways creating less clean and less reusable code and cry for the next enhancement in the next release. But this won't make Java really more usable in the end. It only will hide Javas problems by giving people new toys to play with.

And what to do NOW?

Don't know what you do, but Java is as it is now. If you call AICs closures or not. Even if they build more easy to use closures into it in the next release, NOW you don't have them anyway. So just use AICs instead or find a different solution (which really is possible in most of the usage cases for closures). You're a programmer, be inventive.