Inspired by the APL thread I though I'd bring up a topic that I've been thinking about for a while now:How widespread is the use of functional languages like Haskell and OCaml in quant finance? I 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).I'm a computer scientist myself and it would be interesting to hear what people from other backgrounds have to say.

I haven't done any functional programming since 1994, so have to admit I may be a little out-of-date, but the impression I got was that while it's quite good whenever you need a proof of program correctness - particularly in safety critical applications (like what to do when a nuclear power plant is about to go critical), it's rarely used in any other non-academic environments.I did however find this...http://homepages.inf.ed.ac.uk/wadler/re ... tmlMichael

"I haven't done any functional programming since 1994..."Well neither do I!But it seems to me that you can now do in C++ what you can do in CAML if you use templates.Look at Boost C++ library for example: The metaprogramming in there reminds me a lot of CAML.

Simon Peyton Jones (one of the creators of Haskell) has a fun paper on using functional languages to describe option contracts. http://research.microsoft.com/Users/sim ... htmHaskell is great fun - but in my experience it's not widely used outside academia.

Thanks for the infoOne of my problems is to emulate functional programming techniques in C++, without too much such. What I want is LESS encapsulation insrtead of more (sounds like heresy). For example, I would like to have instances (objects) of an Option class:Object 1 Has price(), delta() functionsObject 2 Only has price()C++ does everything at compile time, so all this is difficult.Can Haskell address this problem?

Daniel,Come to the dark side, embrace the "Real Language" (tm) instead of trying to re-implement it in C++! :-)You don't have to implement everything in Lisp though - foreign function interface lets you link to libraries. See http://uffi.b9.com/ for example.

Temnik> Come to the dark side, embrace the "Real Language" (tm) instead of trying to re-implement it in C++! :-)RightieOh, I'll start immedilately. Just one problem: most of my customers use C++.BTW, why the macho language?? It does not become you

Don't worry - I understand the hardships of having to run a business. Customers - they're always tying you down. :-)Seriously, I am not a licensed computer scientist (only play one on Wilmott), but in order to implement Lisp-y things in a statically-typed language is very messy. You have two ways, it seems:1) Everything has to be a pointer: you'll call functions by pointer with all arguments specified through vararg. Those functions have to return a pointer again.2) The base Option class has to be full of pure virtual functions for every imaginable scenario. Most of them will have to return something silly like MAX_DOUBLE - and you will have to check for it before using the return value. And if you happen to run out of "spare" methods, you'll have to extend ALL derived classes.It can be done - see librep at http://librep.sourceforge.net/ - but librep is GNU-licensed.P.S. What macho language?

> 1) Everything has to be a pointer: you'll call functions by pointer with all arguments specified through > vararg. Those functions have to return a pointer again.DD Not in my software; I use property sets> 2) The base Option class has to be full of pure virtual functions for every imaginable scenario. Most of them > will have to return something silly like MAX_DOUBLE - and you will have to check for it before using the > return value. And if you happen to run out of "spare" methods, you'll have to extend ALL derived classes.DD I do not have classes, just Prototype-based stuff like SELFIn short, to a cerrtain extent I have made C++ a little bit more flexible with the help of templates. After all, C++ was meant to be a safe compile time language. No language is perfect.>> P.S. What macho language? >> In a man-to-man fight, the winner is he who has one more round in his magazine. Personally, I find this statement distasteful. Leave these to Arnie S. In Judo, the winner is he who uses the strength of the opponent against that opponent.

QuoteOriginally posted by: CuchulainnTemnik> Come to the dark side, embrace the "Real Language" (tm) instead of trying to re-implement it in C++! :-)RightieOh, I'll start immedilately. Just one problem: most of my customers use C++.BTW, why the macho language?? It does not become you I dont mean this as a slight on you - please dont take it as such.But if I had a consultant who so bent to the basic nature of C++ (which I had chosen precisely because it is more or less standard and I can have that code maintained by "ordinary mortals" after he has left) that is is not really a compile time type safe language any more I would have very strong words with him. Once.Are you sure this is a smart idea? If you really are handing over a black box then use the language you like (Haskell or OCAML) but if you're handing over code then I think it's dubious ethically to hand over stuff that a good but not exceptional C++ guy cant follow.Just my tuppence worth - clearly I dont know your client base like you do.

linuxuser99 wroteAre you sure this is a smart idea? If you really are handing over a black box then use the language you like (Haskell or OCAML) but if you're handing over code then I think it's dubious ethically to hand over stuff that a good but not exceptional C++ guy cant follow.I am understanding where you are coming from ...To answer your question: 1) your assumption about black code in C++ is not valid in my case (and that of my company) because we have a *standardised* development process using OO analysis and design techniques. First we analyse, then design using DESIGN PATTERNS and blueprints and then implement in C++. It's just like building a house or mechanical engineering. That's the way it SHOULD be done.2) Normal and novice C++ programmers can understand our code, again because we have standardised our coding practice (in building, a plumber or electrician has a standard practice).Conclusion: you are probably describing current practice. Just because C++ is a bit of a mess sometimes does not mean that you can use Haskell. TWO WRONGS DONT MAKE A RIGHT. I woild like to think that the code in my book is readable. I hope I understand my customers. I have been in C++ since 1987 and Design Patterns/OMT/UML since 1990. I have seen quite a few disasters in my time. That's why I use Standard Reference Models (documenetd in my Domain Architecture + UML book (WILEY)).Your assumptions are not applicable in my situation, because my golden rule is that software should be MAINTAINABLE and EASY TO UNDERSTAND.Hope this helps.SEE threads Datasim C++ self-test Datasim Design Patterns self-test

>> Your assumptions are not applicable in my situation, because my golden rule is that software should be MAINTAINABLE and EASY TO UNDERSTAND.Fair enough. Good answer.I've just seen too much code written by people who think that code which looks likexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxis better than XXXXX XXXXXX XXXXXX XXXXXXXXXXbecause doing it all on one line shows off how studley they are.Sounds like you have a more considered approach.As a digression: Personally when I was coding lots I used to try to write stuff that an average to poor guy chould follow (so no marginal language features, lots of formatting, very clear comments etc) even if he couldn't do the logic himself. Means that I often had "sub optimal" implementation at the expense of maintainability - an explicit trade off. Personally I think that while C++ is a bit broke it's basically not bad and unless you need eg formal verification or something really funky (eg time series data manipulation) you're better off sticking to mainstream languages. For me this is C++, C# or Java and something scripty (Python / Perl / TCL). Playing with other stuff is fun (and educational) if it's only me who has to live with it after.

> Means that I often had "sub optimal" implementation at the expense of maintainability - an explicit trade off. I agree with you. Some programmers and 'bitneukers' (to use a naughty Dutch word) still think that they are working on a Commodore 64K machine. Memory costs nothing these days and is efficient. Programmers cost a bucket of money, productivity is too low precisely bacause they concenrate on performance at the MICRO level while the real problems are at SYSTEM level. Blueprints? What are they?This problem is endemic. Change the focus and life becomes more palatable. I think that I must have trained between 4000 and 5000 developers since 1990, so the problems are known.I am glad that my new house behind the dykes has been built to engineering standards. Universities need a change in mindset. That's another story.

http://www.paulgraham.com/noop.html

Paul Graham writes ...Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anywayVery sweeping statement from Mr. Graham. Actually, IMO big companies tend to use Structured Programming, not OOP. This thread is getting into faction fighting. Temnik, if you study my background material you will see that I use 3 paradigms1. OO2. generics (this is NOT OO)3. proceduralWe need all 3 in real appsBTW, a mediocre programmer is always mediocre no matter which langauge he uses.