
Caml Trading: Experiences in Functional Programming on Wall Street - frr149
http://www.janestreetcapital.com/minsky_weeks-jfp_18.pdf
======
mas644
It's fascinating to see FP being used in the "real world" rather than
academia! I absolutely love OCaml and use it all the time to write major
projects. I've always loved the type inferencing and super strict static
typing of the ML family of languages. I wish people would embrace statically
typed languages more...there's a lot to be said for code correctness and OCaml
does it in a very natural way. That and the compiler can usually generate
significantly better performing code.

I always notice those at Jane Street rip on the OO aspects of OCaml. The place
I found classes/objects to come in handy are when you write extensible
software frameworks...though I agree, usually you can do without. However, it
is worth taking a look at how OCaml approaches objects...quite different from
what you would find in your typical C++/Java/C# style language.

The lack of concurrent garbage collector is really becoming a limitation with
the trend towards higher number of cores on a single die. However, because the
GC and compiler are so simple, OCaml is one of those languages where you can
look at object code and understand what the compiler is doing. What's even
more interesting is that even though the compiler is really simple, it does a
fantastic job at optimization. The creator of the language, Xavier Leroy, is
often quoted as saying that "worst case 50% performance of C code".

Oh one other thing...for those that have not tried a functional language, I
think OCaml gives the best introduction. You can code imperatively with it if
you want, but you'll ween yourself off of it in time in exchange for more
declarative, functional techniques. Oh and you won't look back! ;)

~~~
cpeterso
> even though the compiler is really simple, it does a fantastic job at
> optimization.

The paper also refers to OCaml's simple compiler and optimizer. This is
surprising, considering OCaml's fast benchmark showings and functional
languages' reputation for slow, memory intensive code. Is the OCaml team
researching more advanced optimizations or is "worst case 50% performance of C
code" considered good enough (compared to the tradeoff of a more complex
implementation)?

~~~
mas644
You know how it is with benchmarks...it can vary so much. I'm not sure how
much work is done these days on the OCaml compiler. I recall there being a big
debate a few years back about it, a lot of people cried foul that OCaml
benchmarks were close to C/C++ speeds because of the heavy use of OCaml's
imperative constructs (rather than writing functional style implementations of
the code).

In my experience with OCaml, you can write efficient code that approaches
C/C++ speeds if you know how functional language compilers work. The biggest
performance killer in functional languages is efficiently implementing
closures on a stack based machine (i.e. funarg problem). OCaml is smart in
that it implements activation records on the stack if it can tell that a
function won't return a closure. If you're writing in a heavily functional
style, you'll inherently create a lot of closures and lots of heap-based
activation records (i.e. less efficient). At the same time, the compiler can
do a lot of interesting optimizations that would be difficult in an imperative
language. Pretty much every OCaml book including the official manual describes
all the various places where you can have performance penalties and what OCaml
is doing underneath the hood. Also like any half decent functional compiler,
OCaml performs a lot of inlining which results in huge performance gains.

One thing to note, a big part of the reason why OCaml as well as other ML
languages and Haskell have such great performance compared to other functional
languages is because of very strict and static typing. For example, one of the
interesting restrictions of the OCaml type system when dealing with objects is
that you cannot downcast an object once it has been upcast (i.e. like a C++
dynamic_cast). Though this restriction is annoying, the generated code never
has to do any runtime type checking - everything is statically verified!

------
Bootvis
They are a HN favorite but do any HN'ers work there? If yes what's your
experience?

~~~
frr149
Even better, are there any other trading firms using functional languages?

~~~
lrm242
Some more info: [http://quant.stackexchange.com/questions/303/is-f-used-in-
tr...](http://quant.stackexchange.com/questions/303/is-f-used-in-trading-
systems)

Also, if you want to consider Scala:
[http://quant.stackexchange.com/questions/298/is-scala-
used-i...](http://quant.stackexchange.com/questions/298/is-scala-used-in-
trading-systems)

~~~
gtani
this one too

[http://quant.stackexchange.com/questions/306/what-
programmin...](http://quant.stackexchange.com/questions/306/what-programming-
languages-are-most-commonly-used-in-quantitative-finance)

------
rorrr
Video:

<http://video.google.com/videoplay?docid=-2336889538700185341>

