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 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.
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?????
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 $$.
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.