If you've decided you simply cannot tolerate the testing software available on the market; if you've decided to design your own software, your way, then ignore what others have done. Do it your way. When you're all done, if you discover you want to change something, then change it. You've only got one customer to please.
If your goal is to work for yourself, then spending a lot of time developing a backtesting application doesn't accomplish that but rather increases the date when you will be able to leave your current job. Why not just get a profitable strategy up & running that can be developed in a retail product and then branch out from there? If the issue is the way that the software handles errors in intra-day data, why not use daily data thats easier to deal with in that respect? IMO you'll reach your goal quicker if you think about things in that manner.
Frankly, I personally was chomping at the bits to get my first strategy concept/idea implemented, backtested, and rolled out. Now that the strategy has been rolled out and being incrementally improved, I have more time to gradually pull out and replace the pieces I dislike. The NinjaTrader backtesting problem I mentioned above... it's annoying, but I already know a so-called work around. (Basically, start with a clean database, download all of the relevant historical data in one run, and then disconnect from the datafeed.) Not very satisfying at all times, but workable. The backtesting engine is probably last on my list of things I want to implement myself.
Why do you think backtesting progresses you to freedom? It simply helps you find multiple trading methodologies that are unlikely to work in the future. This is what many do and this is one reason many fail. It does not matter if the MACD was at point Y while RSI was in range W to X and the ADX was doing Z. This is almost always coincidence, not discovery...
to the OP... if you just want to prototype, amibroker or wealth-lab will get you there for the mid-frequency stuff. i'm sure there are other packages that would be equally useable. for high-freq or large scale mid-freq, imo, you'll need to roll your own. at that level, no package will be plug and play and will require significant tweaking and coaxing to learn and to get to work... time which would be better spent on your own framework.
Python is a an excellent programming language without question. But if you plan to test your strategies on historical tick data. Forget it. It's a dynamic language and so it's orders of magnitude slower than static languages like C#, Java, etc. But you wouldn't notice that very much on daily data. It would only bite you on tick data or if you do a lot of optimizing.
Most all the platforms only keep the last X bars of data. To get the very first one, just store it when you see the first bar.
You are so right. Hmm. I wonder if TickZoom or TradeLink (both open source) solve that. I don't think so but maybe you could add it yourself.
That is absolutely true. If you really want to write your own. Then use open systems like TradeLink or TickZoom (or both) and combine them with other open source tools. Writing your own software these days never means writing every line of code yourself. You can always piece together different open source solutions. Frustratingly, nothing really good for trading platforms exists on Java open source. Only C++ and C# but those can integrate without too much trouble.
That is so true for 90% of people who try back testing. Just like trading in general, it seems less than 10% master any given technique of trading. So, clearly the odds are against any one person due to all the ways you can do back testing incorrectly. I guess that contributes to the chaos theory, doesn't it?