in my experince I have seen as follows... if you are on a specific desk then you use c++, perl/python, database, excel/vb, vendor APIs, and write crap code fast if you are in research then c++, perl/python, database, matlab/splus, and write crap code if you are writing trading systems then mostly c++ with python/perl logic in fault tolerant quality. But this is not quant stuff
if you are writing trading systems for yourself then you use 'whatever it takes', and write "exceptional code"!
I believe that what segv was referring to in the original post was *guaranteed* performance not necessarily fast performance. Languages that have garbage collection such as Java and Python cannot guarantee response times because the application code cannot control when the garbage collector is run. Furthermore, the behavior of the GC will very likely differ between VM implementations. There is no such problem with C/C++. Garbage collection can be fairly expensive.
Exactly right! Most quant code is poorly written - there are many reasons for this - eg in a rush to implement and test a pricer for some weirdass exotic derivative, cause the trader is standing behind you yelling why it wasn't implemented yesterday, so they end up coding like a monkey to get it out. Funny how a lot of the 'prototype' code ends up in production - even in top-tier IBs. With regards to your last statement, it is also true, but it never ceases to amaze me how most people here believe quants write trading systems - the majority do not.
Its called quality of life. Its a real buzz to work alongside some brilliant people - eventually you have enough of working for 'the man', plus it doesn't help if you enjoy your morning sleep-ins. You have to put in some fierce hours working as a front-office quant for a top-tier IB - its a little easier in risk but still not good if you get to the stage where you want to start a family and actually spend some time with your wife and kids. Or if you simply wish to enjoy life and party. Nothing beats working for yourself.
I think Python is the best language for <i>independent</i> quantitative traders. There is a fundamental difference between our business model and that of a large hedge fund or investment bank. We need to have efficient, agile development processes in order to deliver good results quickly and cheaply. If I were coding a model used by 100 traders managing a billion dollars, sure I'd spend few months coding it in C++. But in reality I'd much rather crank it out in a week in Python and get on with making money. Maybe it runs a bit slower, but that's still a good tradeoff for my business model. With that said, if I were hiring a programmer to replace me, I'd probably ask him or her more C/C++ questions than Python questions. Like Nitro pointed out, someone with proven C skills can learn Python in a week, but it doesn't work the other way. Martin
Yes, it can. For example, numerical code in Python can be almost as fast as C code by using array constructs. It all depends on your application. I'd certainly agree that interpreted code is much slower than complied code. That doesn't mean that a Python application is necessarily much slower than a C application. I recently profiled a quantitative model I wrote in Python and ran in the standard Python interpreter. It was spending more than 90% of its time in pure compiled code (i.e. not the interpreter). I'm sorry, but you couldn't be more wrong. There are languages that are used primarily for scripting and are ill suited for large scale development. Based on my own experience I would include both Tcl and Perl in that category, although others might disagree. Python is extremely well suited to large project development, indeed better suited than either C or C++. I am speaking from extensive personal experience. Python typically gets much more done per line of code but has fewer bugs. Incidentally, Python and Ruby are both strongly typed languages. (You seem to have confused dynamic typing with weak typing.) Few people would consider C to be strongly typed, though it does have a semblance of static type safety. Martin