This article is very good, and having read the conference paper earlier in the year I finished it with only one question: What's a 'quant' ... and is it good or bad to be one?
"Ten years ago, Jean-Marc Eber, then a quant at Société Générale, ..."
The OED has: .. So perhaps he was tall, thin and fond of wearing a cap?
:-)
You might want to try http://www.dictionary.com/cgi-bin/dict.pl?term=quant An expert in the use of mathematics and related subjects, particularly in investment management and stock trading. ... http://www.investorwords.com/q1.htm#quant One who performs quantitative analyses. Or more generally, a securities analyst. Am I the only one who finds the exclusive emphasis on combinator languages slightly disappointing (in fact, the article seems to equate functional language with domain-specific combinator languages, which is more than a bit mistleading)? This is a Haskell forum, not one on Backus' FP, so readers are well aware of the advantages of functional abstraction. Domain-specific languages, if embedded in Haskell, tend to inherit these advantages, even if the language in question was designed as a pure combinator language. The consequence (and the intention, as far as one can gather from the paper) of the limitation to combinators is that this language can and will be used mainly in non-functional languages, not inheriting all that much from a functional style of programming. The same will probably hold for any communication standards based on it. This appplication is undoubtely a success and a good step forward, but there is more to functional languages. The paper somewhat downplays the role of embedding the combinator-based DSL in a full functional language while also mentioning that some features gained for free in the Haskell prototype considerably complicate implementations in other languages. I would be interested to hear more about these aspects: - Is the strictly combinator-based approach a pragmatic necessity ("one step at a time") or is there no need for more advanced features (especially abstraction) in the application area? - Has there been a comparison of the way the combinators of the DSL are used in Haskell and in other implementations? I would think that the use of abstraction to define more complex instruments in terms of the basic combinators should play a rather dominant role. On the other hand, I can imagine that users would want to have each complex instrument explicitly named and studied, instead of trusting large amounts of money to anonymous abstractions created on-the-fly. - What about interactive exploration of new instruments, e.g., in a Hugs or OCaml session (as opposed to changing a C++ implementation, or a stand-alone executable generated by an OCaml compiler, for every experiment)? Claus