This is an evergreen. I've been discussing this with many people - without any clear-cut conclusion. The answer and the preferred solution depend on your trading style (e.g. frequency), your skills, the size of the team, and many other factors.
For simplicity, I call "Research" the Matlab/R/etc. environments, whereas "Live" refers to the re-programmed C++/Java/C# environments.
The proponents of reprogramming usually claim that the two environments are very different in nature, namely:
- Robustness: Research is ad-hoc-ish by nature, your main concern is not speed, programming robustness and style. Production needs to be more robust and faster, and you want to reuse components such as e.g. a price stream.
- Data Research is usually done on a closed data-set: you have a set of in-sample data and wherever possible, you're running backtests with matrix functions (e.g. in Matlab or R). In live trading, you are working on incremental data, new information is popping in irregular spacing. Thus, live trading is much more event-driven (at least for higher frequencies).
- Assumptions In a backtest, you need to make assumptions on the fill ratio and price, and very often you calculate positions asymptotically (i.e. as a percentage of your portfolio, regardless of the minimum size you can hold of a position). In live trading, you can't do that. You need to generate an order in terms of size of futures/shares/etc. Also, you will need to feed back in your actual position (which depends on the fills you got), which is something you don't have to worry about in research.
People usually try to overcome these differences with different strategies, such as:
The Python way take the middle route by building everything in a high-level language that possibly fits both requirements. The opponents of this strategy claim that this way you won't end up with best-of-breed solutions, neither in research nor in live trading.
The Matlab/R way Research-centric shops try to build everything around Matlab. In my experience, this works well to a certain size, but with larger teams things can get very difficult to maintain. Re-usability of components among the team can become very difficult.
The Reprogramming This requires either very good skills or a dedicated re-programming team. This is usually expensive and difficult, and the risk is to add errors.
Integration There are some platforms that allow you to deploy strategies in multiple languages (e.g. compiled matlab code, R automation, etc.). If done well, this may be the best solution.
For yourself, if you're the only one working on the strategy, and with the frequency you mention, the The Matlab/R way sounds like the way to go.