back
28 comments
Taken from one of the examples :

  final HAppend<HCons<Boolean, HNil>, HCons<Double,
  HCons<String, HCons<Integer[], HNil>>>, HCons<Boolean, 
  HCons<Double, HCons<String, HCons<Integer[], HNil>>>>> one = append(zero);
It's here that I miss the repurposed auto keyword of C++ to do some rudimentary type inference.

    final boolean b = a.exists(new F<String, Boolean>() {  
      public Boolean f(final String s) {  
        return fromString(s).forall(isLowerCase);  
      }  
    });
It's here that I miss lambdas to make functional code at all readable.
exactly the example I was going to cite. In Scala this would be

val b = a.exists(str=>str.forall(_.isLowerCase))

or

val b = a.exists(x=>x.toLowerCase() == x)

There's no way I'd start using functional programming in Java if it's this clunky. Just stick with Scala.

Enumerable.java (http://enumerable.org) is not really a functional library, but it does support limited closures:

boolean b = a.any(λ(s, s.equals(s.toLowerCase()));

s and λ are statically imported.

Or C#'s var keyword, for that matter. Unfortunately, both will only work for local variables. I suspect this is one of the reasons there aren't any popular persistent data structure libraries around for these languages. At least the .NET/C# type system supports covariance/contravariance for functions ("delegates"). Plus, they managed to build F# on it.
F# doesn't in fact make use of {co|contra}variance: it only needed generics. (Although F# used to run on .NET 1.x using its own implementation of generics - Don Syme designed both .NET generics and the F# language.)

For type inference, you just need a sufficiently smart compiler, although it's much more useful if your language knows about generic types.

Thanks for clearing that up (I've yet to try F# in anger). I suppose pre-generics F# did similar type wrangling to Scala's?
I don't know about Scala, but yes, wrangling describes well what F# used to do.

I never used F# before .NET 2.0, but the techniques it used on 1.x could be interesting -- I'll see if I can find some old documentation...

Edit: There used to be a paper describing the technique. I can't find it now, but here's an old Don Syme announcement related to it: http://www.mail-archive.com/dotnet-rotor@discuss.develop.com...

Although I was initially skeptical about lombok's "let's hack the private compiler APIs", I must admit that their recent val hack is awesome:

http://projectlombok.org/features/val.html

I find it frustrating that these guys can hack in "val" but JDK7 has token crap like the "diamond operator".

Great Job!!

To those wondering why not move to Clojure or Scala instead of this approach, here is why I am holding back:

a) I have a mission critical enterprise app that is in maintainance mode. I need to enhance certain features dealing with concurrency -- my team can ramp up Actor model implementation in functionaljava or Jetlang faster than they can ramp up on Scala.

b) No doubt that Scala is actually better Java , but I am confident that later versions of JDK would catch up. The concurrency features of JDK 7 are pretty good.

c) did I mention the team -- its hard enough finding a good java programmer; imagine how difficult it would be to hire good Scala programmers from the small eclectic community of Scala programmers.

d) most of the enterprisey stuff my team develops doesn't require functional programming -- just reliable applications delivered within drop dead deadlines. Plain old Java gets me there . JDK 7 concurrency and various Actor model implementations in Java such as FunctionalJava, Jetlang , Kilim are just cherry on top.

It would be actually easier to hire a good Scala than a good Java programmer because most Scala programmers are good. PG has an essay on this phenomenon somewhere.

I'm also not confident that Java will "catch up" to Scala. There's more to Scala than concurrency or functional programming. Type inference, first class objects, short syntax for FP, persistent datastructures, a better object system, etc.

I agree with your opinion about Scala.

However, my point was that Java will continue to be always good enough to steal thunder from more promising languages. ( I realize that Oracle may find a way to screw it up)

Had JDK 7 not included Fork/Join and had Actor model implementations such as Jetlang, Kilim and FunctionalJava not been developed, there could have been a strong case to call Java dated and explore Scala in the enterprise. I began exploring Scala / Clojure to deal with multicore CPUs .concurrency etc. but that is no longer a valid concern.

Java was never elegant to start with -- it just barely got the job done -- and continues to get the job done and that is good enough.

They say that when you have a hammer, everything looks like a Nail. Java is my hammer.

> its hard enough finding a good java programmer; imagine how difficult it would be to hire good Scala programmers from the small eclectic community of Scala programmers.

It seems likely that it's hard to find good Java programmers precisely _because_ the skilled devs are tired of Java and see Scala as a way out.

> I am confident that later versions of JDK would catch up

With the current situation with Oracle, Apache and Google I'm not entirely confident that the Java language will evolve in any significant way.

Or even better than using libraries for functional programming in Java, learn and use Scala. You can mix Scala and Java code where needed.
I second Clojure for a functional programming language on the JVM. Why anyone would want to do functional programming in Java is really beyond my comprehension though.
Scala is and object oriented and functional. People don't count it in the functional languages listings because it's not a pure functional language, that's all.

Here's a nice 108 page presentation, named Pragmatic Real-World Scala.

http://www.slideshare.net/rawwell/pragmaticrealworldscalajfo...

Or Clojure for that matter.
scala != functional programming http://enfranchisedmind.com/blog/posts/scala-not-functional/

It does have functional programming constructs though

Clojure is a much better candidate for FP on the JVM.

http://enfranchisedmind.com/blog/posts/what-is-a-functional-...

Note: NOT written by same guy who did "Scala not Functional".

Everybody has a different definition of FP in mind with these, uh, parameters:

- "no hidden side effects"; clearly demarcated IO functions, database calls.

- curry, partial function application; lexical closures

- TCO

- 1st class, higher-order functions

- Immutable / persistent collections / data structures

Altho most people agree that these are orthogonal to the definition of FP, (but nice to have:

- type inference (ML's is variously referred to as Damas-Milner or Hindley-Milner) or static typing

- lazy eval

- pattern matching

- green/lightweight threads with message passing OR STM/MVCC

- monads,arrows, functors, CPS

http://stackoverflow.com/questions/485418/distinctive-traits...

http://stackoverflow.com/questions/1112773/what-are-the-core...

is scala FP? Usually FP languages are :

- lisps and schemes: CL, racket,

- the ML/erlang/haskell axis incl ocaml,

- spoken of in reverent tones: dylan, clean, mozart/oz

- the JVM/CLR languages: clojure, F#, scala, groovy, jruby

Well you have the answer:

"- the JVM/CLR languages: clojure, F#, scala, groovy, jruby"

Yes, it is, it's and OO and FP.

You are right. But scala does not make it any harder if one chooses to write functional code.
Does anybody know if there is a library like this for C/C++?
After a quick Google, I see there are a few. So I change my question to: has anybody used and liked/disliked one of these libraries or a similar one?

The main ones I could find were FC++ and FACT:

http://www.cc.gatech.edu/~yannis/fc++/ <http://hci.usask.ca/people/ragu/writings/FunctionalProgrammi...; http://www.fz-juelich.de/jsc/FACT/Old_Pages/fact_index.html http://www.boost.org/doc/libs/1_45_0/libs/functional/index.h... http://okmij.org/ftp/cpp-digest/Functional-Cpp.html or <http://www.haskell.org/haskellwiki/Calling_Haskell_from_C...; :)

I have played with FC++ a little bit. Its nice, but if you are used to scheme it will feel verbose. But one cant really complain, C++ wasn't really meant for this.

  java -jar clojure.jar