Dunno much about cash FX - I assume that you only maintain best bids/ offers and not when they go out of scope in your book? Say a new bid is inserted and you have a resting order on what would be level 2 now on the bid, do you still maintain that level in your book?
Most hedge funds do not even have a web site and it's near impossible to get your hands on their investor letters or fund presentations (which, in turn, contain nearly nothing of value). Why would any fund care to tell the world anything at all about their process of alpha generation? I have worked with and I am still working with enough stat arb people to formulate my own opinion on the topic. Majority of people I know use some sort of interpreted language for prototyping and back-testing and re-factor the models to C++ or Java when it is time to trade them live. While this does take some extra time, it adds yet another layer of proofing your strategy, especially if the process involves translating vectorized logic to event-driven code. I have seen people who have written automated trading systems in VBA+Excel and I have seen people who use C for finding alpha in credit derivatives space. As I said, there are so many ways of generating alpha that any sort of absolutist approach ("only A is the way", or "it's wrong to use B for X" or whatever) is plain silly.
I would agree with amazingIndustry that it's pretty rare to see functional language (or any sort of interpreted languages) in a production trading process. For R&D purposes, especially once you got the data in/out all sorted out, it's hard to think of something better.
Sle, can you elaborate further on the usage of functional programming in your process? What functional language are you on, and do you use any libraries? How do you manage interoperability with your existing system (database, trading, administration, visualization); and is this different in r&d and production phase? Do you re reimplement your solutions in your preferred low level language, and what is your strategy for this? I figure many of the high level aspects of functional language don't translate so easy?
Actually, we did run trading strategies in R thru' the IB API, on a 5-min frequency, using an algorithm that wasn't hugely simplistic or computationally trivial. The stability issues we encountered were mostly IB-related (disconnecting), the executions were efficient. The programming brains elected to write our recent backtesting routines in C++ and will probably use it for the future execution process. Thus, I might agree with elements of your argument, but strongly disagree that R is only "to play/toy around with ideas". The rich menu of packages available makes it relatively simple to build models, validate ideas and backtest strategies. There are an increasing number of shops in various strategy spaces who use it as a foundation for their work. IMO, this isn't a 'black or white' issue, and for non-HFT strategies a blend may be the right answer.
Every respectable fund I know and have worked at/with, have a website, I do not follow your point regarding this. A number of funds publish papers on technical implementations (not strategies). Jane Street (on ML and OCamL), LMAX (disruptor) to just name two. And ok, there may be some funds who use Matlab or R even for execution purposes but that is a truly rare breed. And yes, I agree with you a lot of people use interpreted languages for profiling purposes, I never contested that fact. However that is my exact point: For that precise reason it takes most funds months to move a strategy from profiling state to production even if all the results speak for an implementation. Also, there is a reason most funds look for quant traders that can implement models with very short turnaround. Most quants are unable to do so. They know how to profile in R or Matlab or Python (because thats the only languages they really learned and used in grad school), but they have no idea how to port them into C++ or C# to run in production. On the other hand many IT teams have huge issues with moving such profiling code into production and thats the exact bottleneck where all the time is wasted. Guys who test on a C# or better even, C++ engine, access KDB or other columnar databases and are ready to go live take days - weeks after the risk and strategy has been signed off by senior management. I do not understand at all why Python is so popular on the street other than that it is for the lazy due to its ease of use. It is incredibly slow in profiling complex strategies, I have never heard of a single person saying that they are happy with its performance. Why would you use Python if you can profile orders of magnitude faster with a compiled language plus the benefit of moving it into a production environment in no time? I just do not see the argument, never saw it. I worked for years on the sell-side before moving to hedge fund environments and then started my own fund. Most teams are your typical quant heavy geeks with an incredible academic arrogance. They know how to run theoretical models, then you throw at them a limit order book and ask them to measure execution impact and they are totally lost. They are great at using libraries OTHERS CREATED but its incredibly hard for them (or they do not bother to spend the time) to really merge their skill sets on the modeling side with more market and trading exposure. I am not saying all, I am saying I have seen tons of teams like that. It was always that I liked the guys the most who came in fresh, with a mix of coding experience in compiled languages (because it proves they have actually done the thinking part themselves not "stolen" from other libraries") and "screen time". I would always chose to hire a guy who knows how to code C++/C#/Java and who was a day trader for a year over a PhD without any financial market experience but a top shot at R or Matlab. But I am glad we all beg to disagree, we need differing opinions otherwise where are the inefficiencies, that we try to extract alpha from, coming from otherwise...
toy around in a sense that it will take you minutes-hours to run a back test or optimization even on simple strategies over a year worth of tick data. I do the same in about 20 seconds on my compiled language platform. Plus, if you really want to run a limit order book and simulate price takers and makers on a fill simulator you end up with pretty much the same number of lines of code in R than C++ or C#, where is the benefit left? I said toy because its great if I wanna quickly calculate intra-day realized vols between two different assets or portfolio stdevs. We can argue about how complex you can go in R before you hit memory, latency, and throughput walls, in summary they are still very slow because most libraries are not fully taking advantage of multi core machines or distributed computing environments. I guess this is where we are getting to but most libraries are still far away from that goal. Fair point that its not purely black and white. I guess I look at things from a intraday and higher frequency perspective, R or Matlab should be fully sufficient for people who look to develop longer frequency trading strategies. Not saying intraday strategies cannot be profiled in R or Matlab but...well you know my points by now...
...so if someone wanted to choose either R or MATLAB, for prototyping purposes only, on longer frequency strategies, coming from an Excel/VBA environment, and hoping to integrate the new tool (R or MATLAB) with Excel and perhaps some C++ code in the future... would you recommend R or MATLAB? In my specific case, I would be very interested in hearing if either option works better in conjunction with Excel. Btw, thank you for the strong opinion regarding C++. I've heard quite a bit of cheering for the R/Python combo. Personally, I typically prefer to learn what is best over what is easy, so the C++ comments were duly noted.