Best Language for developing a backtesting platform

Quote from GloriaBrown:

May be it would be so hard to build a live trading system with these uncommon languages. Do you have strategies on hand? The strategies are still the cord part. I think for backtest/live trade system, just pick a way to build it in shortest time is the key if making money is the goal.

Yes, definitely. But, I am not in a rush, just doing it on the side as a hobby. So building a data collection server in Erlang (as an example) in order to learn that language would carry other benefits. It's just a way to hedge my risk as I might spend time tinkering with strategies only to discover that they won't work very well in real-time/forward testing. (Again, just a hobby, I'm not doing this for some fund or anything).

Anyway, now that I'm thinking about it, designing such a system in a way that makes sense isn't so cut and dry... a pure monolithic approach likely makes little sense. I don't want to build my own DSL so thinking what language to use for designing the trading strategies and how to architect this aspect of the system merits a bit of deeper consideration. And, Julia would not necessarily be a bad choice based on my experience. I was able to pick it up very quickly. I like Python, but found Julia to be more pleasurable and performance seems quite good. (This would be far better than recompiling my app in C++ every time I change a strategy! Yes, this is what I did years back... fun times).
 
Sound like you are much more into programming than trading strategies:D :D :D May be getting a developer job in Investment bank is your real interest:).

Quote from murrica:

Yes, definitely. But, I am not in a rush, just doing it on the side as a hobby. So building a data collection server in Erlang (as an example) in order to learn that language would carry other benefits. It's just a way to hedge my risk as I might spend time tinkering with strategies only to discover that they won't work very well in real-time/forward testing. (Again, just a hobby, I'm not doing this for some fund or anything).

Anyway, now that I'm thinking about it, designing such a system in a way that makes sense isn't so cut and dry... a pure monolithic approach likely makes little sense. I don't want to build my own DSL so thinking what language to use for designing the trading strategies and how to architect this aspect of the system merits a bit of deeper consideration. And, Julia would not necessarily be a bad choice based on my experience. I was able to pick it up very quickly. I like Python, but found Julia to be more pleasurable and performance seems quite good. (This would be far better than recompiling my app in C++ every time I change a strategy! Yes, this is what I did years back... fun times).
 
Quote from GloriaBrown:

Sound like you are much more into programming than trading strategies:D :D :D May be getting a developer job in Investment bank is your real interest:).

You know, this is starting to sound like a good plan.

1) Build a trading system using decent software architecture principles, and learn new languages/techniques in the process.

2) Develop trading strategies with system.

3) If trading strategies turn out to be wildly profitable trading my own accounts, retire early. If not, use systems and experience in creating them to obtain a lucrative developer job.

I do have lots of ideas for trading strategies, but a custom system to test these strategies is necessary to qualify and refine them. I had started doing this years back but real life took over. Once upon a time I spent 15-18 hours a day coding up strategies.. what a wild time. Just hard to justify without being financially independent (way too risky, time consuming, for something that might have no financial gain, etc.)

Might be a good change of pace from working on web apps (which is consistently profitable for me).. seems my heart is more in trading, though.

Thanks for that.
 
Do you build android or iphone app? Financial lucrative developer is high stress long working hours high pay job comparing to other IT jobs, well it is very excited if you like it. Better to be not married and no kid LOL.

Quote from murrica:

You know, this is starting to sound like a good plan.

1) Build a trading system using decent software architecture principles, and learn new languages/techniques in the process.

2) Develop trading strategies with system.

3) If trading strategies turn out to be wildly profitable trading my own accounts, retire early. If not, use systems and experience in creating them to obtain a lucrative developer job.

Might be a good change of pace from working on web apps.. seems my heart is more in trading.

Thanks for that.
 
Quote from hftvol:

why did you leave out C#/.Net? Its extremely fast to develop, soon the number of libraries for C# will surpass those available in C++, if it has not already. Go to Stack Overflow, pretty much the majority of true professionals (we could define them users with 10k+ votes or whatever) code every single day in C# and those are the guys that drive parts of Google, the SE network, ....unless you are developing stuff for u-hft I highly recommend to test and evaluate in C# when choosing a higher level compiled language.

Of course if one is well versed in R/Matlab then it can be done there, but R by nature is quite slow, though there are packages out there that now handle large memory allocations, parallel computing, concurrency, and even GPU outsourcing.

Seriously? "drive parts of google" has zero to do with reading in numerical information from a file, performing calculations on that read data, and cout results to the screen. For this, C++ is the king, period, fastest, end of story. If you really want it FAST, forget about graphics, you should be smart enough to know what the numbers mean. I can understand how the younger generations don't know how to handle raw calculated results, how they need graphics to understand things. But the raw numbers are all the output you need.

Who cares if it takes a while to code it, good code always does. The payoff is in how fast it runs and how easy it is to change parameters and change data files. Backtesting is simple programming. Ridiculously simple. You may need a few libraries like math, some vector stuff, but nothing complex.

Most guys get so wrapped up in backtesting to avoid the real game in trading which is managing risk. Backtesting is simple, the code should be a simple as possible to get the numerical data you seek. Done. End of story. Now go become a great trader.
 
Only HFT speed would request C++.

Quote from pairsarbtooo:

Seriously? "drive parts of google" has zero to do with reading in numerical information from a file, performing calculations on that read data, and cout results to the screen. For this, C++ is the king, period, fastest, end of story. If you really want it FAST, forget about graphics, you should be smart enough to know what the numbers mean. I can understand how the younger generations don't know how to handle raw calculated results, how they need graphics to understand things. But the raw numbers are all the output you need.

Who cares if it takes a while to code it, good code always does. The payoff is in how fast it runs and how easy it is to change parameters and change data files. Backtesting is simple programming. Ridiculously simple. You may need a few libraries like math, some vector stuff, but nothing complex.

Most guys get so wrapped up in backtesting to avoid the real game in trading which is managing risk. Backtesting is simple, the code should be a simple as possible to get the numerical data you seek. Done. End of story. Now go become a great trader.
 
Im just saying basically i see a huge trend among programmers is that they are really programmers and not traders. Nothing wrong with that, with making your testing code as cool as possible. I am also saying that too much optimization if it is optimization of your code to make it super cool or over optimization of trading parameters in backtesting to curve fit, all are quite common symptoms of those who really don't want to trade, and use over programming as a proxy for that. By putting an imbalanced emphasis on code, they avoid facing the relevant issues that traders need to face and working on those.

It is better to find a trader that has a passion for trading, they key aspect being able to live in uncertainty, and have him or her learn to code, or have him/her learn enough about coding to know coding is not for them and outsource it to a great programmers, than to find a programmer who is at heart a programmer and hope they can trade, it rarely works, and I don't care how good or cool the programming is. I see most computer programmers as very left brained and needing certainty, that's one of the reasons they code is because they love seeing the computer do the task exactly as they envisioned it. I am not saying it doesn't happen, though. Its just my experience that coding testing and automation may be necessary but not sufficient to trade successfully.

Shape your idea, make the code robust enough to test the idea, then go and trade. I made more money manually trading than many people with automated systems, or just using simple vb code before I learned C++. The only thing code rally helped with was reducing the time I spent actually trading, and helping me backtest new ideas and crunching results so I can give my investors industry specific metrics on the system historical performances before going live. It doesn't negate the set of skills necessary to become a good trader, no programming will likely ever do that.

If you really want to test a system, you can use plug in easy language type programs or just learn a little c++, import your data from a text file, read the data into your code, run your calculations, then output the results. That is easy enough to do after a few weeks of learning the language. Easy to compile, debug and run.

The speed of c++ is necessary when you are searching and sorting because the time is a logarithmic function for complex sorts and searches. C++ gives you so much more flexibility, you can even code your code to change parameters and search for the best results, best sharpe ratios. So you can teach your code to create and test new systems. The is time you can spend doing something else. If you think a fast language is not important for this then I would hardly trust your judgement in code and/or trading. It is very significant when your increase the complexity of your code by one or two orders. Did i mention it's the fastest? So you are telling me speed isn't important.............................seriously?????
 
Quote from GloriaBrown:

Do you build android or iphone app? Financial lucrative developer is high stress long working hours high pay job comparing to other IT jobs, well it is very excited if you like it. Better to be not married and no kid LOL.

No native mobile app development, just don't want to spread myself thin.

Yes, the idea excites me, just not sure of the pressure/expectations.. working 80-90 hour weeks is a bit excessive, imo, regardless of the $$.
 
For personal level, you can increase the speed by buying better hardware.

Quote from pairsarbtooo:

Im just saying basically i see a huge trend among programmers is that they are really programmers and not traders. Nothing wrong with that, with making your testing code as cool as possible. I am also saying that too much optimization if it is optimization of your code to make it super cool or over optimization of trading parameters in backtesting to curve fit, all are quite common symptoms of those who really don't want to trade, and use over programming as a proxy for that. By putting an imbalanced emphasis on code, they avoid facing the relevant issues that traders need to face and working on those.

It is better to find a trader that has a passion for trading, they key aspect being able to live in uncertainty, and have him or her learn to code, or have him/her learn enough about coding to know coding is not for them and outsource it to a great programmers, than to find a programmer who is at heart a programmer and hope they can trade, it rarely works, and I don't care how good or cool the programming is. I see most computer programmers as very left brained and needing certainty, that's one of the reasons they code is because they love seeing the computer do the task exactly as they envisioned it. I am not saying it doesn't happen, though. Its just my experience that coding testing and automation may be necessary but not sufficient to trade successfully.

Shape your idea, make the code robust enough to test the idea, then go and trade. I made more money manually trading than many people with automated systems, or just using simple vb code before I learned C++. The only thing code rally helped with was reducing the time I spent actually trading, and helping me backtest new ideas and crunching results so I can give my investors industry specific metrics on the system historical performances before going live. It doesn't negate the set of skills necessary to become a good trader, no programming will likely ever do that.

If you really want to test a system, you can use plug in easy language type programs or just learn a little c++, import your data from a text file, read the data into your code, run your calculations, then output the results. That is easy enough to do after a few weeks of learning the language. Easy to compile, debug and run.

The speed of c++ is necessary when you are searching and sorting because the time is a logarithmic function for complex sorts and searches. C++ gives you so much more flexibility, you can even code your code to change parameters and search for the best results, best sharpe ratios. So you can teach your code to create and test new systems. The is time you can spend doing something else. If you think a fast language is not important for this then I would hardly trust your judgement in code and/or trading. It is very significant when your increase the complexity of your code by one or two orders. Did i mention it's the fastest? So you are telling me speed isn't important.............................seriously?????
 
All true in my experience as well. The only thing I will add is that if your testing and live systems diverge (are different tools etc) then this could be dangerous from many standpoints.

If the testing and live systems time frames are nearly identical, this does not matter much. For example, if your testing time frame uses one minute bars and you are trading on one minute bards, then the system used for back testing and live system may not matter much. However, say your testing is one minute bars, but your live system is a market making system, this is too large an expanse and danger lurks between the real world and the testing world.

I am comming more and more to the conclusion that historical data is worthless if you don't replicate exactly the same way it came to you over the socket. So instead of storing ticks, store the network packets captured by some tool. Then when testing, replay those packets (problably using the same tool used to capture the packets) to your software. Now you are forced to deal with "realtime" data even in testing, and your analysis and live results are far more likely to match.

Quote from murrica:

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.
 
Back
Top