## Monday, December 03, 2007

### Will Closures in Java 7 help in making Functional Programming mainstream ?

Of late, there has been a lot of discussions on the usage of advanced programming idioms in the developers' community. Are we getting too much confined within the limits of strongly typed object-oriented paradigms and ignoring the power that dynamic non object oriented languages (read functional languages) have to offer ? Some of the blogs put forward the strawman's argument dismissing the usage of dynamic languages and more powerful abstractions as somewhat elitist and not suitable for the mass programmers. C# has added lots of functional paradigms to the language, Microsoft has positioned F# as a mainstream functional language for the .NET platform. Ruby has lots of functional features, Erlang has started being in the limelight and Haskell still reigns supreme amongst all favorites in reddit postings.

Still the adoption rate is not heartening enough and there are enough indications of apprehensions from the corners who make the masses. Is it the fear of dynamic typing or the lack of tools for refactoring support that's holding us back ? Or will the functional programming support from today's most widely used enterprise language can act as the catalyst towards easier adoption of folds and unfolds ?

I am not much of a believer in the strawman argument. But I think the push has to come from the medium which controls the balance and there is no denying the fact that today's enterprise programmers do Java for a living.

How close are we to getting closures in Java 7 ?

Do I get ..

public static <T,U> U fold(List<T> us,{T,U=>U} fun, U init) {    U acc = init;    for(T elem : us) {        acc = fun.invoke(elem, acc);    }    return acc;}

even though I would like to have ..

public static <T,U> U fold(List<T> us,{T,U=>U} fun, U init) {    if (us.size() == 0) {        return init;    }    return fold(us.subList(1, us.size()),                fun, fun.invoke(us.get(0),                init));}

Either way I should be able to write ..

List<Integer> ints = new ArrayList<Integer>();//.. populate intsfold(ints,      {Integer elem,Integer acc=>elem + acc},    0);

With Neal Gafter's prototype, I can already write this, though we need TCO in order to play around with meaningful functional control structures.

Ricky Clarkson said...

Gah. Haskell is not dynamically typed at all. In fact, it has complete type erasure - no types exist at runtime.

Dynamic typing is not equivalent to functional programming whatsoever - in fact most of the innovation in functional programming comes from statically-typed languages like Haskell, Clean and Scala, these days.

Debasish said...

@Ricky: I did not tell that Haskell is dynamically typed. What I meant was that the fear for dynamic typing and lack of tools have also led to lesser adoption of functional paradigms in the programming world. Two of the most popular languages to support functional programming today - Ruby and Erlang are dynamically typed. Hence if we get static typing + functional paradigms from Java 7, then it can act as a catalyst for increased adoption of functional paradigms amongst today's enterprise programmers. A developer using Java today can more easily define a fold in Java 7, since he is familiar with the language and can relate that it is not that difficult to pick up a new technique of functional abstraction. Then tomorrow he will also try out Haskell since his initial fears towards functional programming have been allayed through Java.

Neal Gafter said...

I think there is a reasonable chance that jsr292 will provide support for TCO in JDK7.

Flying Frog Consultancy Ltd. said...

Perhaps surprisingly, OCaml is already as popular as Haskell and Erlang on the Linux OS, according to the Debian and Ubuntu package popularity contests. OCaml and Erlang are also the fastest growing functional programming languages.

Ricky Clarkson said...

Presumably OCaml is needed by some programs then, because you're the only user I've noticed.

Many people refer to it as something they used to do, though often fondly.

By what measure is OCaml the fastest growing functional language?

Are you returning to Scala soon? I enjoyed parts of your posts to the Scala mailing list.

Flying Frog Consultancy Ltd. said...

Hi Ricky,

The Debian and Ubuntu package popularity contests track the number of installs of each package among the subscribers to the contest.

Here are the current number of installed development environments for the most popular functional programming languages:

OCaml: 5757
Erlang: 5626
Common Lisp: 4680
Scheme: 3651
Scala: 189

As you can see, OCaml is among the most popular, with many thousands of registered installs (and many more will not be registered). I already knew this, of course, because we have hundreds of paying customers using OCaml extensively in their work, ranging from chip design at Intel to shoe making in Italy.

I recently measured the increase in popularity over the past month:

OCaml: 551
Erlang: 548
Common Lisp: 360
Scheme: 334
Scala: 18

The error is quite big because these values fluctuate but you can see that all of the functional languages are basically growing at the same proportional rate of ~10% growth per month, i.e. there is no evidence for a current favorite language that is exploding in popularity.

Scala is not yet anything like as popular as OCaml. As a company we have discovered that we can turn a profit from product lines built around languages that are at least as popular as OCaml, which means we could potentially earn money from Haskell and Erlang (and F#) but not yet from Scala.

Although Scala is an interesting language, as a pioneer of functional programming on the JVM, I feel that its design has not learned sufficiently from the ML family of languages (e.g. as F# did). The most glaring omission is the lack of automatic generalization in Scala, which means you must define lots of types unnecessarily. This is one of the main sources of the brevity of the ML family of languages and it is sorely missed, essentially rendering Scala much less suitable for the kind of interactive technical computing that we specialize in.

I believe that we need a new functional programming language that draws upon the relative merits of Haskell, OCaml and F#. I am working towards the goal of creating this language using LLVM as a backend. My preliminary findings are amazing: LLVM makes it easy to achieve and even exceed the performance of OCaml's current implementation (which is famous for being the fastest functional programming language there is) in a variety of important test cases.

The main problem is that we do not yet have a GC and run-time, not even a working example. However, I believe it will be easy to obtain performance between that of Scala/F# and OCaml for GC-intensive code simply because the JVM and .NET are optimized for Java/C# which makes them ~5x slower for functional programming.

plush said...
photo soft said...
said...
said...
said...
said...

said...

said...

said...

Anonymous said...