Joined: Nov 2005
Thu Feb 03, 11 10:52 PM
Originally posted by: bojan
Originally posted by: spv205
I don't believe its used for derivatives pricing, where you want rock solid performance, managing 1000s of trades in a fixed well defined process.. (eg end of day runs, Value at Risk etc)
I believe its mainly used for algo /quantitative trading, where you are keen to prototype new strategies, and constantly tinkering with old strategies/ fine tuning etc.
These uses sound about right but I don't think the reasons are. If you are doing algo/quantitative trading than you really need to have 100% confidence in your implementation -- if something goes wrong you lose real money right away. If the risk runs look a bit funny or don't go through, that is a bit of a problem for the management but you've not crystalised any losses. For Algo, people sometimes prototype in Python and then hand over to Java programmers for implementation.
I think one of the reasons are is that people who do risk systems haven't yet caught up with Python, and risk/pricing systems have a lifecycle of many years and so change rather slowly.
But there is an interesting point here -- writing large systems in Python is quite different from little programs and scripts. I've found that when you have more than about three people working on a large Python project it becomes quite tricky and requires a great deal of discipline and the right skill- and tool-set. So, large Python projects are not always an unqualified success.
Python is easy to learn (in fact, it was originally designed partly with that end in mind). I personally find it very pleasant to use. Lots of others feel similarly and consequently there was a vogue 5-10 years ago for using it as a ready-made scripting environment and yoking it to C++ in-process.
Sadly this ended in tears everywhere I saw it done.
The problem was that python and C++ object lifetimes and typesystems do not align perfectly and so there is a fair bit of finesse involved in joining the 2 languages correctly - to the extent that I have never actually seen it done well.
Also, you start off getting seduced by the (extreme) ease of interfacing Python and C-style languages, but then the effort of shipping an embedded runtime kicks in - and what if there is another python engine in-process? Perhaps this is something Python offers more options on nowadays though.
Those looking for a non-C++ way of scripting now seem to be more looking at purely functional languages, perhaps Haskell, accessed via cross-process calls. Personally that's a route that I'm keener on following myself nowadays too if I had to do something now.
But I am working on other things than quant libs nowadays and so am holding out for something that can combine imperative and functional approaches well. God only knows when that will turn up.