Caml Trading

Caml trading – experiences with functional programming on Wall Street
by Yaron Minsky and Stephen Weeks
Journal of Functional Programming, Volume 18, Issue 04, July 2008, pp 553-564

Functional programmers are always keen to gather evidence that it is actually of use in the 'real world'. Jane Street Capital, by adopting O'Caml as the language in which they write the programs that earn them so much money, has provided one of the clearest demonstations. Yaron Minsky delivered a brilliant invited talk to this effect at POPL 2008, and I'm delighted to see that he and Steven Weeks have now published a companion article for JFP.

An error in a financial program of this kind can wipe out a firm's profits for the year in a few seconds, so reliability is a concern. The partners of Jane Street review the code themselves, and this turned out to be one of the major factors influencing the adoption of Caml.

I thought their comments on OO programming were of interest.
When we first tried switching over from VB to C#, one of the most disturbing features of the language for the partners who read the code was inheritance. They found it difficult to figure out which implementation of a given method was being invoked from a given call point, and therefore, difficult to reason about the code. It is worth mentioning that OCaml actually does support inheritance as part of its object system. That said, objects are an obscure part of the language, and inheritance even more so. At Jane Street, we almost never use objects and never use inheritance. We use standard functional programming techniques and code reviewers find that style more comprehensible. In particular, they can reason by following static properties of the code (module boundaries and functor
applications) rather than dynamic properties (what class an object is).
I've had similar thoughts about the perils of inheritance, but this is one of the few places I've seen them documented.

I come from an entirely different place - I do web programming in Python (my language of choice since 2004), but I categorically avoid inheritance for precisely the reasons your quote mentions: inheritance harms readability and comprehensibility. I am absolutely delighted to hear the same message from a completely different quarter. Thank you.

As a side note, it turns out that Allen Holub shares this view: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
It's interesting to how FP seems more natural and easy to understand for some, while OO seems more natural and easy to understand for others. Either one side is "wrong" or different people think in different ways (like being left or right handed) and the best we can do is give each the tools suitable to themselves and find ways to make our different tools seemlessly integrate.

I dug out this description by Luc Duponcheel who opined that "scala" being a hybrid of both OO and FP allows the programmer to have the cake and eat it.

OO => object oriented programming languages have elegant constructs for modeling problem domains

FP => functional oriented programming languages have elegant constructs for writing algorithms

Article with the same name was published in The Monad.Reader Issue 7.

I am curious what are the differences between these articles.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?