"..best direction for evolving Java is to encourage a more functional style"

So, generic type erasure is still a bad idea.

To the best of my understanding, lambdas-as-objects would mean providing structural types, i.e. generic function types that are able to describe the structure of a lambda (arguments and result type). e.g. (a fictive syntax):

    Function0<Int> f = () => 5

f here is a lambda that take no args and returns an Int. It's type is Function0 (0 for no args) and parameterized with the return type.

Another example with 2 args:

    Function2<String, Float, Int> f = (String name, Float rate) => 5

The Function* types are the generic structural types able to describe lambdas. C# has them, and so does Scala.

Java however decided not to have them, because they don't adhere well with Java's history with nominative types (a type has a name that carries sense). They rather came up with the SAM auto conversion, which is a neat idea in itself, but a bit less flexible than structural types, and may (and will lead to a Cambrian explosion in the number of types, e.g. Reducer, Mapper, Folder, Filter, Predicate, etc.)

What's even worse though is erasure: Java generics are erased at compile time, and this fucks up things really bad with overloading, so in a code like this (in the type List for example):

    public <S> List<T> stupidOpName(Function1<T, S> f) { ... }

    public List<T> stupidOpName(Function1<T, Boolean> f) { ... }

After erasure, we'll end up with :

    public List stupidOpName(Function1 f) { ... }

    public List stupidOpName(Function1 f) { ... }

i.e. 2 methods with the same name and same signature. This is bad. You don't ever want that to happen. And fortunately the java compiler won't let it happen.

So, the alternative is I said SAM (Single Abstract Method) types: no structural types, but lambdas can be automatically converted to a SAM if compatible, so you could do this for example:

    Runnable r = () => { ... }

The lambda gets converted to the Runnable type.

Lambdas as objects vs lambdas as higher order functions is primarily about state. Lambdas make poor objects, especially in the absence of pattern matching; as soon as your API needs more than one method signature, you need to overload things, and you can get caught up in reimplementing the equivalent of Smalltalk message-send. If you want to make an object, you're usually better off using an object (or anonymous class etc.) when the language provides it.

Using lambdas to parameterize algorithms gives you more power, and if the algorithm can assume that the lambda passed in is stateless, it can do things like memoize (cache) calls to it to further optimize the algorithm. Lambdas as higher order functions help you make more composable libraries, because often the glue needed to join one bit of code to another is just a transformation of the return value of one function to the parameter type of another. That's an ideal application for a lambda.

For example, take sorting a list of objects by a particular attribute. A sort routine can be written that takes in a comparison routine, and that comparison routine can do the work of selecting the attributes and comparing them. But chances are you're comparing things like numbers and strings; you'll have other library code that can do those comparisons. So what you actually want, most of the time, is just the bare minimum: a lambda that, given the object to be sorted, returns the attribute to sort by. That's how the Sort routine works in .NET's LINQ, for example: myList.Sort(x => x.Name) will return a sorted sequence of the contents of myList in the order of x.Name property or field. The lambda here is extremely simple and syntactically light, and that's what makes the pattern work. Above all, the lambda isn't really acting like an object.

Neither Java, nor c#, are simple. They're arguable less complex than things like f# and scala, but its quite a lot about the question of familiarity.

If you're coming from an imperative, oop, background then these languages will require more learning because you're not familiar with the concepts.

But a language like Java is huge by comparison with something like Javascript or python. In terms of the size of grammar, the number of semantic rules required for description, etc.

Priority: 4-Low http://bugs.sun.com/view_bug.do?bug_id=5098163

It's not that they can't update the VM, it's that they don't want to force a painful migration to reified versions of libraries that aren't backwards compatible. But I don't know why they can't just do what that last comment said: extend the old interfaces for reification without breaking them, using Object as the default type parameter.

Common Lisp had safe memory references and garbage collection. It did have CLOS, but I don't think many people used it. CLOS also was a very different take on OO.

The core of Java is the OO programming model, and "good" Java programming revolves around what works in that model.

Lately I've become a fan of "import static", which imports static functions from another class. "import static java.lang.Math." is good to do if you need to do a lot of math, for instance. "import static com.example.mysystem.MyDSL." sets you up to use an internal DSL.

Faking Lambdas with objects is cumbersome but not difficult, and remember there are many tricks like new ArrayMap<String,String>() {{ put("k1","v1"); put ("k2","v2") }} which let you build structures the way you would in Javascript, Python, PHP, C# or whatever.

"Horseless carriage".

"Webcomic".

"Cell phone".

> So, Java will eventually have two different paradigms to code in.

I don't think that's the case. Higher-order functions have been part of the OO toolbox since the batch of OO languages has existed, generally under the label "blocks" (indicating non-local returns separating them from the preexisting "lambdas").

And I'd argue that a language without anonymous first-class function can not be "truly" object-oriented, or at least not without significant syntactic overhead.

To me, a core idea of OO is that objects are opaque boxes to which you "give order" (that makes Erlang's processes excellent objects, by the way). But it is very common that you need to customize the exact behavior in some way.

Without first-class functions, the choices are to either extract all relevant data from the object, perform the operation yourself and (optionally) feed the data back, low overhead but a far cry from object orientation; or to create a new type holding all relevant customization information (that's the delegate pattern), very high overhead but remains object oriented.

First-class functions in OO language act as very-low-overhead delegates (you may still need full-blow delegates for complex customization, but single-method delegates aren't needed anymore), and let language users avoid imperative programming.

JavaScript is kind of functional. It pretty much forces you to use functional stuff like closures.

It's not a pure functional language, but it's sure not pure OO either.

Using objects and a functional style aren't mutually exclusive. Use objects for encapsulation and abstraction and use a functional style for clarity, conciseness, expressiveness and less mutating state.

I think it's a fair statement to prefer the OO paradigm, and indeed it is good for a whole load of things in programming. Nonetheless, adding lambdas to Java should give plenty of easy wins even if you prefer your code to be broadly OO.

Look through your for and foreach loops. I bet a lot of them would be neater, more readable, and better express intent as some combination of map and filter.

Count how many classes you have with only one method and no data in them. Would you really make separate classes for all of those if you had the option to pass them around as functions?

I would also like to see something like the yield and yield! (yield every item in this collection) keywords, because those can give readability improvements in a lot of places too, but one step at a time.

I don't really know Java, so this is made up Java/C#/something, but compare these:

    List<int> mapped = new List<int>();
    for (int i = 0; i < list.count(); i++)
    {
        mapped[i] =  list[i] + 1;
    }

Or:

    List<int> mapped = list.map((x) => x + 1);

Which do you think is more elegant and readable? For a slightly more extreme example, what if we want the numbers less than 100:

    List<int>filtered = new List<int>();
    for (int i = 0, j = 0; i < list.count(); i++)
    {
        if (list[i] < 100)
        {
            filtered[j] = list[i];
            j++;
        }
    }

Or this:

    List<int> filtered = list.filter((x) => x < 100);