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.
We need your support and trust!!! Dear friends, please temporarily stop your footsteps To our website Walk around A look at Maybe you'll find happiness in your sight shopping heaven and earth You'll find our price is more suitable for you.
Welcome to our website ( http://www.findsoso.com / )
Thanks to the support!
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.
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.
> 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.
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.
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.
29 comments
[ 2.6 ms ] story [ 53.3 ms ] threadval 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.
boolean b = a.any(λ(s, s.equals(s.toLowerCase()));
s and λ are statically imported.
For type inference, you just need a sufficiently smart compiler, although it's much more useful if your language knows about generic types.
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...
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".
We need your support and trust!!! Dear friends, please temporarily stop your footsteps To our website Walk around A look at Maybe you'll find happiness in your sight shopping heaven and earth You'll find our price is more suitable for you. Welcome to our website ( http://www.findsoso.com / ) Thanks to the support!
( http://www.findsoso.com / ) ( http://www.findsoso.com / ) ( http://www.findsoso.com /
It does have functional programming constructs though
Clojure is a much better candidate for FP on the JVM.
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...
- 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
"- the JVM/CLR languages: clojure, F#, scala, groovy, jruby"
Yes, it is, it's and OO and FP.
Here's a nice 108 page presentation, named Pragmatic Real-World Scala.
http://www.slideshare.net/rawwell/pragmaticrealworldscalajfo...
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 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'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.
With the current situation with Oracle, Apache and Google I'm not entirely confident that the Java language will evolve in any significant way.
http://sourceforge.net/projects/fcpp/
http://www.boost.org/doc/libs/1_45_0/doc/html/lambda.html
http://boost-spirit.com/dl_docs/phoenix-2/libs/spirit/phoeni...
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...; :)