views:

1932

answers:

8

Will there be a functional language which does for the Java community what F# does for the .NET community?

What functional programming languages are available, or in development, for the JVM?

+32  A: 

Scala would be the language.

Though not strictly functional (it's a mix of functional and object-oriented) and it is not strictly for Java (there is a .NET version of Scala), that would be the closest analog to F# in the JVM.

jop
Yep, Scala is the answer.
Brad Wilson
I too agree that Scala is the correct answer.
SCdF
F# is not strictly functional either - you can program using OO/procedural if you like too :-)
kronoz
Scala:functional::C++:object-oriented
Chuck
Congratulations on your Populist badge
Milan Ramaiya
+15  A: 

The first thing that came to my mind was Scala but really Ocaml-Java comes closer as F# is a variant of Ocaml. See this post that compares Ocaml-Java to Scala:

OCaml programmers are typically over 10x as productive as Java or C++ programmers for a wide range of practical tasks. Despite being based upon a fundamentally OOP platform, F# goes a long way to capturing the productivity- boosting benefits of OCaml (and the whole ML family). In contrast, Scala fails to capture many of the benefits including some really basic ones and, consequently, writing correct code is much more difficult in Scala than in any real ML.

Moreover, the ML family of languages are designed to be succinct but Scala is needlessly verbose for everything from "Hello world!" upwards. The ML family of languages provide extensive type inference (OCaml more than most) but Scala has only rudimentary inference by comparison. OCaml has an unusually expressive type system but Scala adds little to OOP that is of practical importance.

Mark Cidade
While there is no argument that ML/OCaml is a lot more concise and functional than Scala, it is hard to support all of the claims in the (somewhat dated) forum post. I do agree though that Scala does not fit the analogy. F# is basically OCaml for the CLR.
Daniel Spiewak
@Daniel: I'd have to agree fully. There are a few scenarios where F#/OCaml offer this advantage, but for most day-to-day programming (i.e. most people's bread and butter) this claim is simply unrealistic.
Marc Gravell
The author of the linked post (Jon Harrop) commonly trolls usenet and other fora to drum up consulting business. Take his advice with a grain of salt--he's trying to sell you something.
Nathan Sanders
The post doesn't really give any kind of advice--just some select examples that compare OCaml to Scala. Regardless of who the author is the examples are valid and illustrative unless he's making a straw man argument by giving poor Scala examples.
Mark Cidade
Nathan, you're saying that I am not trustworthy because my money is literally on OCaml and F# and not on Scala. That does not make sense to me but I suppose you expect me to value your opinion as a student who has not contributed to any of these language communities?
Jon Harrop
I don't happen to be a big fan of Jon, but as a full time Haskell programmer (who switched from Java and Ruby by choice), I agree with the criticisms he makes in that Usenet post, and the type of features he describes are something I constantly rely on in day-to-day programming.
Curt Sampson
A: 

Actually, I might be wrong, but I don't expect F# to be as mainstream as the other .NET languages; useful in a few circles (academic, compilers, a few other scenarios) - however, don't forget that C# offers FP usage - and it gets better each time: C# 1.2 has delegates; C# 2.0 has anonymous methods and captures/closures; C# 3.0 has lambdas for simplicity, and Expression for abstraction. Anonymous types (C# 3.0) share some similarity with tuples (in terms of convenience), but obviously are very different beasts, so definitely not a like-for-like comparison.

Maybe not quite as optimised as F#, but for most day-to-day FP use-cases, more than sufficient.

It is also quite clear that better support for immutability (especially for threading) is very much on the minds of the C# language team for future consideration.

My money is on C# getting better at FP, and being the .NET FP offering for most day-to-day purposes. Of course, there will be some F# usage - but (purely subjective) I simply don't see there being a huge migration.

Marc Gravell
Does not answer the question. Even if F# remains irrelevant, the question could be asking for the equivalent irrelevant FP language for the JVM.
Nathan Sanders
Ah - a good claim to fame: "just as irrelevant as F#" ;-p
Marc Gravell
Without variant types, pattern matching and HM type inference? You're joking...
Jon Harrop
@Jon Harrop: we've had this conversation before ;-p But yes, absolutely: for the most part, I fully expect people to stay with C#. There is a niche where F# may be desirable, but I personally do not imagine any huge migration. Care to counter with something more concrete than just a "-1"?
Marc Gravell
Downvoters; please give me an indication **what** you disagree with? I'd love to know... is it disgruntled F# fans? Fine: then rather than just downvoting, tell me *why* you think F# is going to have an effect on the *general* .NET community. I agree is has uses in *very specific* scenarios, but for most general line-of-business code it simply isn't the most appropriate tool. If it is people angry I didn't answer the question (i.e. FP for the JVM): IMO, the *premise* of the question is wrong, and I stand by that...
Marc Gravell
The question is: "What Functional Programming languages are available, or in development, for the JVM?".Your answer was a F# vs C# argument. You are answering the wrong question.
fsanches
No, the question was "...which does for the Java Community what F# does for the .NET Community." - my answer merely attempts to put a perspective on this - otherwise, the question is meaningless.
Marc Gravell
+1  A: 

For now I would say Scala. But for the future, I'd have a look at Fortress. The first implementation of the spec was released on April 1, 2008. And no, that is not a joke. Key featues are:

  • Statically typed, but a lot of type inference to avoid clutter
  • Unicode and 2d rendering of mathematical functions
  • Designed for parallel execution (for each defaults to it)
  • Strong support for custom libraries (Guy Steele's influence)
  • Operator overloading, including the juxtaposition operator

More info at the Project Fortress Community website and the Wikipedia Fortress page.

Roel Spilker
If you downvote, please leave a comment to explain why.
Roel Spilker
@RoelSpilker: Wasn't me. Went to the site, couldn't download the spec. Being a Fortran descendant doesn't seem to fit the bill as a functional language? Am I wrong?
_ande_turner_
Although at first glance it look as just a new version of Fortran, it is also influenced by Scala and Haskell. And the way the language is designed, it supports both Objects and Traits. See the FAQ as well: http://research.sun.com/projects/plrg/faq/index.html#five
Roel Spilker
@RoelSpiker: +1 ... Sounds good but I'm wondering as to the General momentum behind it. Their "roadmap" doesn't lead anywhere currently. :s
_ande_turner_
interesting, but probably going to fail! I'll vote up though!
CVertex
Sun made the project open source just after they didn't get a renewal from DARPA, even though they had a running prototype/proof of concept. Since then, a lot of people got involved and helping improving Fortress. But I couldn't find who leads the project.
Roel Spilker
Fortress is dead. It was never even designed, let alone implemented...
Jon Harrop
+13  A: 

Perhaps Clojure. It's not statically typed, but it has more of an emphasis on immutability and concurrency than F. However, like F# (and unlike Common Lisp), it is intended to be a primarily functional language that it good at consuming OO libraries from the underlying platform.

Nathan Sanders
Glad you like it. I wish more people liked Lisp syntax...
Nathan Sanders
I'd prefer Dylan's syntax
Mark Cidade
+1 'cause its right, and it puts you at 10 which gives jop his Populist badge
Milan Ramaiya
A: 

@Marc Gravell - functional languages are increasingly used in the guts of enterprise grade financial systems. We use many functional (pure or "semi-pure") at the bank I work for...

That doesn't change anything... I said "as mainstream as the other .NET languages", and I'll stand by that. I expect there to be more non-FP code than FP code in most business systems for a considerable time.
Marc Gravell
This should probably have been a comment, not a post, btw.
Marc Gravell
+5  A: 

Arguably none because the JVM lacks tail calls and they are required to make almost all functional code robust with respect to stack consumption.

The nearest thing to functional language implementations on the JVM are Clojure, Scala and the OCaml-Java project. Although there are workarounds for the lack of tail calls (e.g. trampolining), none of these language implementations do this because the workarounds introduce even more serious problems, e.g. crippling performance and completely obfuscating debugging.

Sun have been talking about tail calls for years and, more recently, have indicated that they intend to implement them imminently. As soon as that is done, I am sure we will see a lot more language diversity on the JVM and, in particular, some production-quality functional language implementations. Until then, I regard all of these languages as toys.

Cheers, Jon Harrop.

Jon Harrop
+1  A: 

There's a good list of programming languages for JVM, including functional programming paradigm and other paradigm languages on:

  • en.wikipedia.org/wiki/List_of_JVM_languages

My first pick is Scala (multi-paradigm; OO & FP), I spent a 5+ months studing Scala in 2009, and created a quick reference sheet: bchiprog.blogspot.com/2009/05/scala-cheat-sheet.html

I noticed there are other programming paradigms that are interesting, other focuses on parallel processing such as X10, Fortress, and Chapel. X10 is implemented on top of Scala - http://www.scala-lang.org/sites/default/files/odersky/scalaliftoff2009.pdf

It's really based on what problem you need to solve then pick the language that can best solve it. I think it's developers' wish that there's one language that can solve any type of problem easily and doing it simply.

Benjamin Chi