wilmott.com

>> BTW, a mediocre programmer is always mediocre no matter which langauge he uses. Very true - however there are languages in which it is a lot, lot more difficult to be great!

>>> How widespread is the use of functional languages like Haskell and OCaml in quant finance? I can only say for kdb+. It is widely used in electronic trading as a time series database for capturing market data, cep engine, trading system, backtesting, paper whitetrading,... .The language Q itself is not hard to learn. There is no pointer, no memory allocation, no type inference, no oop.As a comparison the following code will generate normal random numbers. Try to implement the same algorithm in c++.Kim

QuoteOriginally posted by: linustHow widespread is the use of functional languages like Haskell and OCaml in quant finance? At Credit Suisse, Haskell were used, but it seems it is not the case anymore. At Barclays they use Haskell (to develop their "Functional Payout Framework", an implementation of Jones, Eber, Sewar articles). About OCaml, it is used at Jane Street, and at LexiFi (I work here. We develop MLFi, our extension of OCaml that implements the Jones, Eber, Sewar articles. Jean-Marc Eber is the founder and still the CEO). Since a few time, there is also Bloomberg that use a little bit OCaml (we licensed them our technology).It seems there is also some IB that use F# but not for quant purposes.QuoteOriginally posted by: linustI get the feeling that many of the models and algorithms discussed here could be expressed very neatly and nicely in declarative form, being highly mathematical. Of course, performance is often an issue but there have been plenty of development in that area (OCaml is a good example).Indeed, a lot of quant algo are very easy to implement in FP (however, with pure FP it can be the opposite, that's why I appreciate multi paradigm languages (like OCaml)). About performances, OCaml is reasonable (with some low level function implemented in C / Fortran). Moreover, FP provid easy way to drastically improve algorithm, eg memoization, or partial application (with precomputations) (note: my opinion can obviously be biased).

QuoteOriginally posted by: VivienBQuoteOriginally posted by: linustHow widespread is the use of functional languages like Haskell and OCaml in quant finance? At Credit Suisse, Haskell were used, but it seems it is not the case anymore. At Barclays they use Haskell (to develop their "Functional Payout Framework", an implementation of Jones, Eber, Sewar articles). About OCaml, it is used at Jane Street, and at LexiFi (I work here. We develop MLFi, our extension of OCaml that implements the Jones, Eber, Sewar articles. Jean-Marc Eber is the founder and still the CEO). Since a few time, there is also Bloomberg that use a little bit OCaml (we licensed them our technology).It seems there is also some IB that use F# but not for quant purposes.QuoteOriginally posted by: linustI get the feeling that many of the models and algorithms discussed here could be expressed very neatly and nicely in declarative form, being highly mathematical. Of course, performance is often an issue but there have been plenty of development in that area (OCaml is a good example).Indeed, a lot of quant algo are very easy to implement in FP (however, with pure FP it can be the opposite, that's why I appreciate multi paradigm languages (like OCaml)). About performances, OCaml is reasonable (with some low level function implemented in C / Fortran). Moreover, FP provid easy way to drastically improve algorithm, eg memoization, or partial application (with precomputations) (note: my opinion can obviously be biased).Functional programming older (Church, 1930s?) than OOP and even Fortran and COBOL. It did not catch on for several reasons. You see traces of FP entering C++, C#.

QuoteOriginally posted by: CuchulainnFunctional programming older (Church, 1930s?) than OOP and even Fortran and COBOL. It did not catch on for several reasons. You see traces of FP entering C++, C#.In your opinion, what are the reason why FP did not catch?Btw, as you mentioned, some features of FP are entering C++ and C#. Moreover, a lot of recent (promising) languages include FP features by default (and have well design multi-paradigm). I think we're going on the good direction with these languages.

QuoteOriginally posted by: VivienBQuoteOriginally posted by: CuchulainnFunctional programming older (Church, 1930s?) than OOP and even Fortran and COBOL. It did not catch on for several reasons. You see traces of FP entering C++, C#.In your opinion, what are the reason why FP did not catch?Btw, as you mentioned, some features of FP are entering C++ and C#. Moreover, a lot of recent (promising) languages include FP features by default (and have well design multi-paradigm). I think we're going on the good direction with these languages.Hi VivienB,My guess is that FP did not take off 1) no compilers at the time 2) esoteric branch of CS research 3) too mathematical for most folk 4) why bother, Fortran and EBNF was fine 5) limited applicability to real life (Fibonacci considered harmful)Back to C++IMO having more FP features and less templates++ is more important for applications. Templates are essentially structural while FP is well, (mathematical) functions. So, for example a PDE solve has a need for FP features such as 1. Function composition.2. Currrying.3. Folding. (pde -> fdm ->..)maybe moreC++ 11 supports 1 and 2 while 3 not (could then use a Visitor).For PDE, objects are useful for 'keeping it all together' while 'inside' the objects all those fps are lurking. I don't think a pure (object-less) FP paradigm is good in this case.An issue is that C++ is imperative which is a pain when configuring an application. FP is declarative.More MLFI-esque languages is probably a good idea.

QuoteOriginally posted by: CuchulainnFor PDE, objects are useful for 'keeping it all together' while 'inside' the objects all those fps are lurking. I don't think a pure (object-less) FP paradigm is good in this case.Yes indeed. PDE is a good example of problem that can be perfectly handled with multi-paradigm (at least object, functional and imperative).QuoteOriginally posted by: CuchulainnMore MLFI-esque languages is probably a good idea.Totally agree .

QuoteOriginally posted by: VivienBQuoteOriginally posted by: CuchulainnFor PDE, objects are useful for 'keeping it all together' while 'inside' the objects all those fps are lurking. I don't think a pure (object-less) FP paradigm is good in this case.Yes indeed. PDE is a good example of problem that can be perfectly handled with multi-paradigm (at least object, functional and imperative).QuoteOriginally posted by: CuchulainnMore MLFI-esque languages is probably a good idea.Totally agree .In the case of a n-factor PDE and it approximations (full FDM, MOL, FEM(?)) some major use cases are:1. How to design these models (e.g. zillion ways to design a PDE thing).2. Configuring a model (instantiation).3. Preprocessing a model (e.g. coordinate transformation in a PDE).4. Transforming a model into another one (e.g. PDE to a full FDM or a MOL).5. Presentation of results (e.g. slices in n-dim data).(6. Underlying data structures.)And the the '-ility' issues like Efficiency, Functionality and Maintainability1-5 typically OOP/FP, 6 is GP?

What do you mean by "GP"?

QuoteOriginally posted by: VivienBWhat do you mean by "GP"?Generic programming. e.g. templates in C++ or generics in C# (or C++/CLI).

Ok. To me it's a kind of FP feature (in the sense that the mains FP languages implement it).For the PDE, there is also all the low level part that deals with matrix operations, and that must IMO use imperative programming.

VivienB: well, some do, some don't.In particular, compile-time generic programming (with the binding & dispatch performed statically but general enough so as to allow for compile-time laziness) is not as common.Let's take Template Haskell as an example: http://www.haskell.org/haskellwiki/Template_HaskellThis is closely associated with type classes, for which, again, while comparable features are widespread, things are rather more interesting as far as the compile-time variant is concerned.Also relevant in this context:- Multi-parameter type classes- (Indexed) Type familiesI'm wondering, how many other FP languages implement comparable features?// I think GP is far more than "generics" implemented by some programming languages. In particular, I find run-time attempts at the implementation particularly limited and generally uninteresting.From the PLT (programming language theory) point of view, Harper (2014) provides an interesting way to look at it (succinct if you're coming from an FP background):QuoteThe generic extension of a type operator is an example of the concept of a functor in category theory (MacLane, 1998). Generic programming is essentially functorial programming, exploiting the functorial action of polynomial type operators (Hinze and Jeuring, 2003).If you're curious / would like more information, take a look at Chapter 13 (Generic Programming), which is the source of the quote:Harper (2014) "Practical Foundations for Programming Languages" Second Editionhttp://www.cs.cmu.edu/~rwh/plbook/book.pdf

QuoteOriginally posted by: PolterI think GP is far more than "generics" implemented by some programming languages.Ok I didn't understood that.However, as you said, in Haskell it is even more than just generics. In OCaml there are module types and functors: http://caml.inria.fr/pub/docs/manual-oc ... mples.html. I guess that in other FP languages there are also other / same cool stuffs to extend generics.Btw, thanks for the precisions and the links.

QuoteOriginally posted by: VivienBOk. To me it's a kind of FP feature (in the sense that the mains FP languages implement it).A strict definition is needed and it does exist.My definition is based on C++ and C# only. definition Generic classes have been a part of Eiffel since the original method and language design.Generics in the context of Haskell seems to be something different. The best term IMO is parametric polymorphism, strictly speaking. Is generalizing it a good idea?BTW C++/CLI supports run-time generics and compile-time templates. // Changing the meaning of words in maths is taboo; CS seems to do it with abandon; why not use the Cardelli-Wegner classification and save confusion? http://lucacardelli.name/papers/onunderstanding.a4.pdf QuoteFor the PDE, there is also all the low level part that deals with matrix operations, and that must IMO use imperative programmingSure. Are the underlying types generic. i.e. Matrix<T>?