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.
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.
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 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.
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.
