Can you please elaborate on that a bit? I didn't know either language and couldn't decide which to use for my live trading. I ended up choosing Java only because IB supported it and not C#. It seems that ever since I've finished it (which was a great idea and way better than what I was using (Amibroker)), all I read is that C# does everything better, ha.
Best Language for developing a backtesting platform
- Thread starter murrica
- Start date
Can you please elaborate on that a bit? I didn't know either language and couldn't decide which to use for my live trading. I ended up choosing Java only because IB supported it and not C#. It seems that ever since I've finished it (which was a great idea and way better than what I was using (Amibroker)), all I read is that C# does everything better, ha.
The StatET Eclipse plugin for R has a full visual debugger (just like VisualStudio) which I use every day and have no problems with. I could not use RStudio because it does not have a debugger.
I think it's fine to prototype in R and later reimplement in C++ or C# or Java . Or mix and match however you want.
The reality is that most initial implementations get thrown away anyway.
I see no reason why it should be so difficult to port to C later if required.
If there were great back-testing and time-series libraries for C# or Java I might go that way, but there are not.
But one can go either way.....
I think it's fine to prototype in R and later reimplement in C++ or C# or Java . Or mix and match however you want.
The reality is that most initial implementations get thrown away anyway.
I see no reason why it should be so difficult to port to C later if required.
If there were great back-testing and time-series libraries for C# or Java I might go that way, but there are not.
But one can go either way.....
I do not agree that C# is faster then Java. Sometimes one is faster, sometimes the other. There are benchmarks all over the web on this and they are not conclusive either way.
Plus Java is portable so you can run it under Linux etc. (I know there is Mono for .Net under Linux but it has issues).
However C# may have an advantage in number of API's offered by brokers in that language.
To jtrader33:
That's just based on experience in both languages, C# is a resource hog like Java, but it does run quicker (on windows at least, Mono is a POS). Realistically, unless you're planning to feed the whole book over multiple years through your back tester, it's not going to make that much difference, however, if you are planning to do that nothing is going to beat C/C++. Viewing it from an execution POV, if you're going over the internet the speeds of different languages are not going to make a difference, so there are lots of trade offs to be made, it's different for each case I guess...
That's just based on experience in both languages, C# is a resource hog like Java, but it does run quicker (on windows at least, Mono is a POS). Realistically, unless you're planning to feed the whole book over multiple years through your back tester, it's not going to make that much difference, however, if you are planning to do that nothing is going to beat C/C++. Viewing it from an execution POV, if you're going over the internet the speeds of different languages are not going to make a difference, so there are lots of trade offs to be made, it's different for each case I guess...
All of the above. In my experience through various walks of life, the chosen tools do not matter much as an amazing maker can perform magic with just a hammer. Having said that, an artisan can certainly leverage the ideal tools.. so if using R to backtest, reimplementing in Java or C++ for a production system works, then it works. If doing it all in C++ works, that's fine too. Whatever gets you there, as one poster pointed out, IMO. Just doing it, doing something that moves you forward, is the most important thing. This surely eclipses analysis paralysis or divergent/irrelevant development paths by huge margins.
I wouldn't be interested in doing anything that is 'HFT' related, so that end of optimization (C/asm/fpga's/extreme colo and horsepower/etc) is irrelevant. What could matter (possibly, not necessarily) is using a fast language like C++ (haskell/erlang/ocaml/?) for backtesting. Maybe hadoop or some other distributed technologies... ec2, leased time.. who knows. My past experience with backtesting was such that having huge horsepower or super leet distributed algos or the like did not matter when sketching out actual auto trading ideas, but I certainly could imagine fucking around with tons of horsepower in creative ways. Who knows, maybe that insane processing could spark some nasty ideas involving scanning huge data sets for... something..correlations in data, patterns...I could surely come up with a zillion ways to permute and iterate and process data to find something that *seems* like an edge..lol.
If, say, R was easy to get up and running and had all the infrastructure in place to write backtests in an organized matter but didn't provide super extreme power, that might be fine, at least initially. I had once upon a time started to roll-your-own backtesting engine which is always less than ideal.
Since my expertise with backtesting financial data is on the order of someone still doing old school PHP web apps with security holes, having the 'ruby on rails' of backtesting wouldn't be a bad thing. What language/framework would be the closest parallel to RoR? R? others? Reinventing the wheel sure does offer limited appeal.
Yes I believe R with the quantstrat package because, like R on R, it is a complete solution with complete trading systems as included examples even! This includes backtesting, reporting, performance statistics (including Sharpe Ratio etc.) , portfolio optimization etc.
My guess is that it would take a year to even begin to implement those facilities from scratch in C++ or Java, and you would probably be still be fiddling to get Sharpe Ratio exactly right etc.
HOWEVER R (S) is partly a list processing language (like Lisp) and partly an array language (like APL) and quite a few people will have trouble learning to program in those styles and will not like it or will find it too slow because they do not adapt to use vector style programming.
Also the choice of tooling is controversial, as was mentioned. Most prefer RStudio, but I would only use Eclipse/StatET, in order to have its debugger. I am sure that RStudio will add a debugger at some point but it is not there now.
