Lambda the Ultimate

One author's feature requests for Java 3.0. I think the most interesting is "Eliminate primitive data types". I think that is one bit of "worse is better" legacy that Java could afford to drop. :-)

There's also some discussion on this wiki page: http://c2.com/cgi/wiki?JavaThree which attempts to construct a more interesting list of changes for a hypothetical Java 3.

First I think a link to the article is required.

It's a bit funny to me that Elliotte Rusty Harold perceives his suggestions to be revolutionary, and thus continuously apologizes for them. While some of his suggestions may have significant repercussions on existing code, none of them appear revolutionary to me. For example, no mention of generics. At the very least he should look at Nice. I think Mr. Harold is so caught up in the Java frame of mind he can't see beyond that language's paradigm.

As to the suggestions on the wiki page, I'm all for closures (one of the main features I miss when programming in Java or C++), but all the examples given are of simple anonymous functions (except perhaps the use of isTheElementWeWant()). BTW, given Java's OOP nature, I think anonymous functions should actually be anonymous methods. That is, they should be methods of the same class as the method in which they are defined. This is so that they can access members of that class.

Maybe it makes sense to be able to create classes on the fly (even this is not all that revolutionary...)

Seems to me Java can learn a lot from other OOP/imperative languages (e.g., Ada, C++, Eiffel and even Python), before starting down the difficult path of integrating OOP and functional programming. [Indeed, I think Python does a nice job integrating some fp features, while remaining true to its original nature.]

Another way of looking at it: In the presence of fp features (hof, algebraic types, lazy evaluation etc.) it may be possible to streamline the language while keeping the basic OOP facilites. Simply adding features tends to make languages less consistent and usable.

I don't see how all these ideas interact.

I don't think they do. This is indeed just a grocery list of useful features missing in Java. Obviously all these features exist in other languages, it's very hard to come up with a feature that doesn't, and I don't think Java wants to be that bleeding edge anyway.

Simply adding features tends to make languages less consistent and usable.

All too true, but it's a fact that Java is missing lots of useful mainstream features. Obviously common sense must be employed while adding such features, and they should be added in such a way as to preserve the spirit of the language.

Is this your model?

What I mean is that the anonymous method not only has access the variables in the scope it was defined (the closure), but also to members of the class in whose method it was defined. Indeed, I believe that this is more easily done, and more in conjunction with the spirit of Java than a real closure (after all Java doesn't even hane named functions, only methods). So in a first version (Java 3 as opposed to Java 4 :) you won't get real closure support, only anonymous methods (unfortunately you probably won't get either).

Maybe it makes sense to be able to create classes on the fly

Java already supports this (see the internal iterator sample in the wiki). As pointed out, however, the syntax is very verbose and a bit hard to read (which may explain C# using delegates instead).

The trick is to find a set of additional features which preserve this spirit so that we end up with a better Java rather than Smalltalk-lite. The archetypal feature in this set would be something like generics: a relatively small change with significant benefits that doesn't compromise the conceptual integrity of the language.

So shopping lists of features that would transform Java into Smalltalk or Lisp or Eiffel are rather pointless because they aren't about improving Java but about replacing Java with some other language.

The harsh lesson to be learned from the success of Java (and possibly C#) is that if people in the mainstream wanted Smalltalk or Scheme (or even Python) they'd be using those languages. The best we can hope for is to smuggle some of the more useful fruits of academic research into the mainstream.

I'm not sure that the spirit of Java can absorb functional programming features.

I'm not sure I can accept this statement as a given. For example, C++ did manage to absorb STL, which includes some functional tendencies. While it's true that C++ represents a more multi-paradigmatic approach than Java, the change was significant. I believe that the Java language and Java users can absorb changes provided they result in visible improvements and approachable code.

For example, looking at one of the samples in the wiki:

list.find(new Predicate() {
  public boolean isTrue(Object o) {
    return isTheElementWeWant(o);
  }
});

Wouldn't it look a lot nicer, even to a diehard Java programmer, if it could be written as:

list.find(boolean(Object o) {
  return isTheElementWeWant(o);
});

or something along these lines. Also note that initially only library writers would have to contend with the syntactic changes required to write to new list.find() method, other developers would simply enjoy it's simpler interface. Later this improvement would trickle down to the masses.

Several mainstream languages are (finally) moving in a functional direction, and it would be a mistake for Java to be left behind.

list.find(isTheElementWeWant);

I agree that class-closure is a poor replacement for real closures. What I was saying is:

1. Java can benefit from both. In fact if you provide scope closure you probably need class-closure as well (you might even get it automatically through the value of 'this').
2. Class-closure would require less changes to the language and the JVM and is better than nothing

Still, I don't like it...

But you don't really like Java anyway. I have to say that this exchange is becoming almost like a chat :-)

It's strange you know I don't like Java. I tend not to talk about Java much, since I am not really an expert. I never built anything compilcated using Java, and I don't really want to learn all the intericate details of the language.

So it's not really that I don't like Java, it's more that I never liked to study it properly

Working with Java is OK, though I'm not balled over. Standard OOP stuff (and the standard problems where some developers think they know OOP but really don't, e.g. lots of static functions). I am missing generics, let me tell you. And closures (which I don't have in C++, my other main language, either) though inner-classes are better than nothing. I am playing with Nice, but I can't imagine we will be using it for any major development any time soon.

Ah yes, and speaking of Nice, Java should also have touples, given that it doesn't support output parameters.

>>>I'm not sure I can accept this statement as a given. For example, C++ did manage to absorb STL

C++ was designed to be a multi-paradigmatic language. I am not sure the same can be said about Java.