Why do hedge funds and financial services often use OCaml?

Speaking to a number of quants / hedgies, I came to the conclusion that a large number of them seem to be using either a homebrew language or OCaml for many tasks. What many of them couldn't answer was why.

I can certainly understand why they wouldnt want to use C++ for the most part, but why is OCaml superior for these uses compared to 开发者_StackOverflow社区other scripting languages, say Python, Ruby etc?

Try reading Caml trading - experiences with functional programming on Wall Street by Yaron Minsky and Stephen Weeks (apologies, while this article used to be hosted for free at Jane Capital, it is no longer there, so I leave the ACM link for reference). They go into great detail about what they feel are the advantages and disadvantages of OCaml, though they for the most part take it as a given that it is better than most other options they considered (i.e. not a lot of direct comparisons with C++, Python, what have you).

The authors work at Jane Street Capital which has invested heavily in OCaml code.

Update: See also the thread What programming language(s) is algorithmic trading software written in?. One of the comments mentions a presentation Yaron Minsky gave at CMU on Jane Street Capital's use of Caml. About an hour long, and very interesting.

Update Two: Yaron has written another overview, this time for ACM Queue, called OCaml for the Masses.

See for example the programming languages shootout for speed comparisons:

• Ocaml vs Python: faster
• Ocaml vs Ruby MRI: faster
• Ocaml vs C++: slower but less code

Now, we all heard the line about lies, damned lies and benchmarks so grains of salt recommended -- but this a fairly well done comparison. At the end of the day it matters what one gets done with one's own problem and data.

First thing to keep in mind, is that even though OCaml has an REPL and clear, succinct syntax, it's not a dynamic language like Python or Ruby. It has static typing and compiles to native code.

For Quantitative Analysis, scripting languages are more convenient. You have access to alot of libraries, it's easy to do quick and dirty scripts to manage information, and building small to medium programs is easy even for a non-programmer.

For creating algorithms and systems which actually engage in trading, you want something like OCaml. The main advantages of OCaml are its functional nature, readability (it reads almost as nicely as a dynamic language like Python), reliability, but mostly speed. OCaml is much, much faster than most people believe - it's C fast (actually slightly slower than C, but many, many times quicker than dynamic languages). OCaml is fast enough to create a HFT system, which isn't something that can be said for either Python or Ruby.

Also, keep in mind Jane Street (the most vocal OCaml evangelist) adopted OCaml before Scala and Clojure came onto the scene.

Being a functional language, it is mathematical in nature, which probably fits in nicely with the kinds of problems these firms need to solve. And as others have pointed out, it has a nice performance profile.

Maybe this is why Microsoft co-opted OCaml for F#

Because it's blazingly fast (and far more succinct than C++).

Picking up on Don's post, Jane Street Captial even has a page dedicated to OCaml, with further links to their OCaml engagement (including a blog).- Performance of OCaml is usually a big argument, but I think also the "quants" love it because the functional paradigm lends itself very well to their kind of analytical work, so I think they are the early adopters. And then firms discover that it is equally suited for systems programming.

UPDATE: The links are mostly broken and cannot easily be updated. Jane Street seems to be less outspoken about whatever remains of their OCaml engagement these days.

Trivial parallelization compared to Python/Ruby? At least this is true for F#, but should be true for Caml/OCaml for much the same reasons.

As much as I love Ruby, it wouldn't be my first choice for heavy-duty tasks that are mostly mathematical or aggregations, and neither Python nor Ruby have really great support for multithreading yet.

The terseness of relatively complex pipelines of calculations thanks to pattern matching and the preference for immutability (harder to enforce in Ruby, slightly easier in Python but still harder than in ML-based languages) are most valuable for calculations on large data sets.

I don't work at a place like that, so these are just guesses as to why I might do it in their position:

It's generally quite a bit faster than languages like Ruby and Python and, as a statically typed functional language, it's generally somewhat easier to reason about the code and know that it doesn't contain subtle bugs. (Yes, unit tests should help catch those as well, but extra assurance that your financial numbers aren't getting screwed up is nice to have.) Also, functional programming is very closely tied to math, more so than most high-level language paradigms (like, there isn't an OO branch of math), so it's good at modeling what they actually do there.

In my experience of Quants it's VBA (read: Excel) with c#, or f# sometimes too. I don't know personally of any Quants using caml...