Java – What are the benefits and disadvantages in the approaches of C#, Java and Scala to Closures/Lambdas/…

cclosuresjavalambdascala

I wonder what the technical implementation differences between C# and Scala are and how both solutions compare to the implementation ideas and concerns voiced in the email Peek Past lambda by Brian Goetz, sent to the mailing list of Project Lambda (JSR 335)?

From the email:

We explored the road of "maybe lambdas should just be inner class
instances, that would be really simple", but eventually came to the
position of "functions are a better direction for the future of the
language".

and further:

The lambdas-are-objects view of the world conflicts with this possible
future. The lambdas-are-functions view of the world does not, and
preserving this flexibility is one of the points in favor of not
burdening lambdas with even the appearance of object-ness.

Conclusion:

Lambdas-are-functions opens doors. Lambdas-are-objects closes them.
We prefer to see those doors left open.

And some comment from a person on the Reddit thread says:

I actually e-mailed Neal Gafter about this and to my limited
understanding of his explaination C# and the current Java design are
quite similar in that Delegates are actually objects and not function
types. It seems like he believes that Java should learn from the
disadvantages of C#'s lambdas and avoid them (much like C# learned
from Java's disadvantages and avoided them in the beginning).

Why does the "Lambdas-are-functions" approach enable more opportunities in the future than "Lambdas-are-objects"? Can someone explain what differences exist and how they would influence how code would be written?

Seeing that things in Scala "just work", I keep thinking that I'm missing something about the approaches taken/proposed in C#/Java (8), probably it is related to concerns about backward-compatibility?

Best Answer

I think the discussion regarding objects vs. functions is a red herring. If the question is, "Is a lambda a function or an object?" the answer should be yes.

That's the point of first-class functions: they aren't treated differently than any other type. Java already manages to mostly ignore the differences between Object and primitive types (and Scala does even better), so whether a lambda is a subclass of Object or is a new primitive type or something else isn't really important for the language. What is important is that you can put your lambdas in collections, pass them around to be called, call them, and do anything else you might want to do with either an object or a method.

Scala accomplishes this by using a wrapper object that has a method called apply which can be invoked with just (), making it look just like a method call. This works splendidly; much of the time you don't need to even care whether you have a method or are calling the apply of a function object.

Related Solutions

What are the biggest differences between F# and Scala

Major Differences:

Both Scala and F# combine OO-imperative programming and functional programming into one language. Their approach towards unification of paradigms is vastly different though. Scala tries to fuse the two paradigms into one (we call it object-functional paradigm), whereas F# provides the two paradigms side by side. For example, algebraic data types in F# are purely functional constructs with no OO'ness in them whereas ADTs in Scala are still regular classes and objects. (Note: In the process of compilation to CLR bytecode, even F# ADTs become classes and objects but they are not visible to F# programmer at the source level.)
F# has full Hindley-Milner style type inference. Scala has partial type inference. Support for subtyping and pure-OO-ness makes Hindley-Milner style type inference impossible for Scala.
Scala is much more minimalistic language than F#. Scala has a very small orthogonal set of constructs that are re-used throughout the language. F# seems to introduce new syntax for every little thing, thus becoming very syntax heavy as compared to Scala. (Scala has 40 keywords, whereas F# has 97. That should tell you something. :-)
F# being a Microsoft language has an excellent IDE support in the form of Visual Studio. Things are not so good on the Scala side. Eclipse plugin is still not upto the mark. Same goes for NetBeans plugin. IDEA seems to be your best bet at the moment, though it doesn't even come close to what you get with Java IDEs. (For Emacs fans, there's ENSIME. I have heard a lot of good things about this package, but I haven't tried it yet.)
Scala has far more powerful (and complex) type system than F#.

Other Differences:

F# functions are curried by default. In Scala, currying is available but not used very often.
Scala's syntax is a mix of that of Java, Standard ML, Haskell, Erlang and many many other languages. F# syntax is inspired by those of OCaml, C#, and Haskell.
Scala supports higher kinds and typeclasses. F# doesn't.
Scala is much more amenable to DSLs than F#.

PS: I love both Scala and F#, and hope they become predominant languages of their respective platforms in the future. :-)

Scala vs Java – Performance Comparison

There's one thing that you can do concisely and efficiently in Java that you can't in Scala: enumerations. For everything else, even for constructs that are slow in Scala's library, you can get efficient versions working in Scala.

So, for the most part, you don't need to add Java to your code. Even for code that uses enumeration in Java, there's often a solution in Scala that is adequate or good -- I place the exception on enumerations that have extra methods and whose int constant values are used.

As for what to watch out for, here are some things.

If you use the enrich my library pattern, always convert to a class. For example:

// WRONG -- the implementation uses reflection when calling "isWord"
implicit def toIsWord(s: String) = new { def isWord = s matches "[A-Za-z]+" }

// RIGHT
class IsWord(s: String) { def isWord = s matches "[A-Za-z]+" }
implicit def toIsWord(s: String): IsWord = new IsWord(s)

Be wary of collection methods -- because they are polymorphic for the most part, JVM does not optimize them. You need not avoid them, but pay attention to it on critical sections. Be aware that for in Scala is implemented through method calls and anonymous classes.
If using a Java class, such as String, Array or AnyVal classes that correspond to Java primitives, prefer the methods provided by Java when alternatives exist. For example, use length on String and Array instead of size.
Avoid careless use of implicit conversions, as you can find yourself using conversions by mistake instead of by design.
Extend classes instead of traits. For example, if you are extending Function1, extend AbstractFunction1 instead.
Use -optimise and specialization to get most of Scala.
Understand what is happening: javap is your friend, and so are a bunch of Scala flags that show what's going on.
Scala idioms are designed to improve correctness and make the code more concise and maintainable. They are not designed for speed, so if you need to use null instead of Option in a critical path, do so! There's a reason why Scala is multi-paradigm.
Remember that the true measure of performance is running code. See this question for an example of what may happen if you ignore that rule.

Best Answer

Related Solutions

What are the biggest differences between F# and Scala

Scala vs Java – Performance Comparison

Related Topic