I'd advise going with Haskell. Haskell's GHC compiler is on par with C compilers, and will leave in the dust the bytecode-compiled languages, JIT or no JIT. This happens because Haskell's design ensure that a wide range of techniques are possible for optimization.

Now, if you are going to stay on the JVM, I'd recommend either Clojure or Scala. They both can use Java's extensive library support. In fact, they both fit all your requisites (imho, since at least one of them is subjective :).

Scala would be easier to pick up, because you can start with the same style you are already proficient with, and introduce functional features as the time goes. Besides, not being solely functional makes it possible to selectively jump back into imperative style if the performance with a functional style for a particular algorithm isn't making the grade. On Scala, look also at the Scala Query (type safe database manipulation), Scalala (linear algebra, matlab-like) and Scalax (serious functional stuff, Haskell-like) external libraries.

Clojure would have the advantage of accelerating functional learning by virtue of being painful to do anything else. I don't know it enough to recommend any Clojure-specific libraries.

I recommend you take a look at those Scala libraries, and any Clojure libraries people recommend, and answers to questions involving code for both languages to gauge the expressiveness and style. As for Haskell... I recommend diving right in -- trying the waters first might scare you. :-)

I like a lot OCaml because it has some very nice killer features that I love:

• Very fast compiled code
• Strong typing that is not a pain in the arse through type inference
• Multi Paradigm (OO, Imperative, Functional)

The worst thing about it is that it's not getting a parallel garbage collector any time soon, so its great performance will be lagging behind other languages implementations that are easier to parallelise automatically as the number of cores increases. It's still possible to do parallel programming explicitly with MPI (but I think that kills the fun).

If you can afford to spend some money, maybe this book could help you: OCaml for Scientists ^[1].

Anyway, I'd stick with Python/SciPy, it's got great performance and a flexibility hard to find in any other language. Being already proficient in both Python and C, I found this book lovely to go deeper in these topics: Python Scripting for Computational Science ^[2]

I can only speak about Clojure since I have only limited experience with the other languages.

The advantages of Clojure:

1. Full JVM integration. You can use any library written in Java, so you will have no dearth of well-tuned, mature libraries, such as those from Sun or Apache Commons. Covers your concerns [6] and [7].
2. Concurrency support. Software transaction memory and Java threads. Covers [5].
3. Incanter ^[1]: a statistical computing package modeled after R, written in Clojure. Under the hood it uses the high-performance, multithreaded scientific computing package Parallel Colt ^[2]. Covers [1] and [7].
4. It's a Lisp, with all the metaprogramming and expressiveness that it entails. Covers [2].

Disadvantages:

1. Relatively new to the scene. The community is small, albeit very active and helpful. It may or may not survive the test of time.
2. It's a Lisp. If you don't like Lisp, then you won't like Clojure, although obviously I'm personally biased and would prefer you gave it a try.
3. Will probably never match Java in pure speed, pound for pound. It generally comes close, within an order of magnitude.
4. It is not a pure functional language. Read: side effects and mutable data structures. This may or may not be a disadvantage to you, depending on what you're looking for out of the langauge.

Scientific computation is two-fold.

Quick prototyping

On one hand you may need to write a lot of prototype code, and need to write it fast. Often, this code is used just once. So, there is a need in simple and expressive languages with solid library support. In my opinion, Python is the best suited for this purpose. And I hope it will finally dethrone matlab in this area. I don't know any of the functional languages which can compete with Python right now.

Performance computing

On the other hand, you may need to solve computationally intensive problems, and performance is important. So, you need an optimizing compiler and parallel computations (both multi-core and multi-machine). And you need to make it work on clusters (i.e. on Linux) and support standard parallel APIs (MPI and OpenMP).

From you list probably only Scheme is not suitable for performance computing. The others may or may not be OK. I don't know. Anyway, the result will usually be 2 or 3 times slower than pure hand-optimized C/C++/Fortran/Java.

I know that Haskell used to lag behind in this area, but with Data Parallel Haskell ^[1] this may change. It's status is technology preview right now (and stable in ghc 6.12?).

There is also a field of symbolic computing, which I am fairly remote from. I expect that some of the functional languages may really shine in this area if there are suitable libraries.

Shootout

I think you can also consult shootout.alioth.debian.org to see the performance limits in similar number-crunching tasks on a multi-core CPU. Sure, pure C rules them all, but most of the compiled functional languages are good enough:

1. Double-precision N-body simulation ^[2]

2. Eigenvalue using the power method ^[3]

Libraries

Scientific computing depends on the existence of libraries in your domain (unless you are ready to write your own). Just for the reference:

Numeric and scientific libs for Python ^[4]

Haskell math libraries ^[5]

OCaml math libraries ^[6]

After Erlang and OCaml you should also look at J ^[1]. It is ultimate scientific language.

Options you didn't list, but should look into:

• Mathematica ^[1]
• R ^[2]

Because of the GUI front end and strong mathematical typography support, many don't realize that Mathematica is in fact a programming language. You don't even have to use the GUI: you can run the evaluation engine in the background, just as they do for Wolfram Alpha ^[3]. As you'd expect of a mathematical programming language, it can be used in a purely functional manner, though it also has procedural and OO features. It's not side-effect-free, as you can have variables that vary, but you can program without using those parts of the language, if you want. It has everything you asked for. The only question is whether you can cope with the license cost.

R is also a functional language, in the same impure way as, say, JavaScript: functions are first-class objects, but there are also variables-that-vary. It's more what the average programmer would think of as a "language" than Mathematica, but pretty much across the board not as powerful except in its primary domain, statistics. It's a general-purpose programming language, not tied to statistics or even math and science, but because so few people use it outside these domains, getting good info on how to use it that way can be difficult.

There probably isn't a definitive answer here, but you certainly aren't the first to ask.

http://lambda-the-ultimate.org/node/2720

http://www.programming4scientists.com/2008/08/a-big-list-of-programming-languages/

I have grown fond of F# which is based on OCaml, but I would think most any functional language would get you to the goal.

I think that Scala can win big in this area. At work I use Scala for data analysis and it works out quite well being a hybrid of functional and object-oriented programming languages. You get all of the Java goodness for free:

• Java standard library
• Huge ecosystem of the Java world (including many numerical, statistical and simulation packages)
• JVM (JIT compilation, garbage collection, etc)

Plus, you get the good stuff which Scala offers.

• Strong and expressive type system (actually type-safe, unlike Java)
• Pattern matching
• Actors for concurrency (like Erlang)
• Flexible syntax for quick-and-easy mini languages (and good parsers for DSLs)
• Native XML type

In my opinion, Scala does a great job of bridging the gap between many different paradigms while still being able to fit in with existing infrastructure.

Clojure and Scala will have the best library support, as they can call into libraries written in any JVM-supported language.

Haskell and OCaml are both mature, well-tested languages. They can interface with existing code written in C, FORTRAN, etc through their FFIs.

Erlang is mature, but while it's often used in fault-tolerant distributed systems, I've never heard it praised on merits of performance. Maybe I just missed the memo? Would probably match any other language if the computations are parallelizable.

Scheme's a great language, but it doesn't have many libraries, and it's not very fast in my experience.

F# has the most potential, as a first-class citizen in .NET/Windows world.

Nearly all functional languages exist mostly as academic curiosities. If that suits your needs, fine. I lean towards the "if its popular, it's not bad." school of thought.

Could always go one up from Clojure and learn Common Lisp (or Scheme for that matter).

...if not Lisp, then I'd probably settle for Haskell (and then Erlang).

OK, I know I'm late... But it seems that Scheme can actually be a good option. There was recently some discussion in the chicken-users mailing list ^[1], and it seems that Chicken Scheme ^[2] can be vary fast for numeric computing using the "Crunch" extension. And Scheme is nice because it's a very expressive language, has support for interactive development and is conceptually very simple.

And Chicken supports lots of SRFIs! There are also other extensions and libraries available (see the Eggs index ^[3]).

a late comment:)

In our data mining research group, several students are using Python on Hadoop to do parallel computing. The result is promising. Since you have a background in Python, this method is faster than learning a new language.

If you really want to learn a FP language, I think clojure/incanter ^[1](on JVM) and F#(on .Net) are the best.

Also notice one thing, FPs does not support numberical computing theirselves, they use C/Fortrain library bindings and a stable binding usually take years!(see Numpy/Scipy)

I am using F# as I am familiar with Microsoft's platforms, also because it is strongly supported by a company experienced in platforms and tools.

I use Clojure for similar types of computation. We do a lot of matrix work, as well as processing of other data structures.

I don't think your question has a single answer. There is no "best" functional language. It all depends on what you do and which libraries you intend to use. For us, the JVM was a huge plus, as it is a mature VM with a good JIT, a number of garbage collectors, and parallelism. All are important to us.

We use incanter for most of mathematical work and Clojuratica/Mathematica for arcane stuff and prototyping.

Implicit is you want library functionality at least equal scipy / numpy/ matplotlib , along with the huge number of C / linux tools available: R, GSL, sage, octave. Also tools to integrate relational DB, key-value and doc stores, hadoop, etc. Probably only java and .NET libs are going to give that kind of batteries included.

Erlang is the only FP language I've learned in anger. It's "mature" for its traditional server/middleware core competency, but there's a recognition that it could do a lot more. For example, web app frameworks need decent regex engine to do URL recognition and generation, and there was that Tim Bray todo about Erlang and apache logfiles (WideFinder) so the erlang core team is working on it (Robert Virding's libraries).

So it's today not a language known for matrix and statistical math, map-reduce and SIMD data analytics, but given its push into new types of apps, it could surprise you, and the VM's ability to spawn, manage, and terminate ten of thousands of processes and more (gracefully) is unrivaled.

Any of these would do, I think (though I don't have a scientific background, so YMMV). Of these my favorites are, in order:

1: Haskell 2: Erlang 3: OCaml / F# (pulled a fast one on this one). 4: Scala