Caml Trading: Experiences in Functional Programming on Wall Street
janestreetcapital.com
janestreetcapital.com
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! ;)
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)?
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!
[1] news.ycombinator.com/user?id=yminsky
Also, if you want to consider Scala: http://quant.stackexchange.com/questions/298/is-scala-used-i...
Tsuru Capital do FP and have advertised jobs on the haskell-cafe mailing list before.
I run technology there.
Feel free to fire me off an email if you'd like to know more.
There are a number of banks mentioned such as Bank of America, Barclays Capital and Cedit Suisse. A company called Allston Trading is apparently using Haskell to do some HFT too.
EDIT: fixed spelling.