Python, desktop platforms and commercial tools

Once a strategy needs portfolios, intraday data at scale, walk-forward, or Monte Carlo, the spreadsheet runs out and you need either code or a dedicated platform. This lesson surveys the common choices without recommending one, because the right tool depends on what you trade, whether you can program, and how much the platform's assumptions match the honesty checks in Modules 2 and 4. Every tool below is real and in use; none of them removes the need to understand what it is assuming.

Python

Python is the default language for serious retail backtesting because the data tools are free and mature. There are three broad styles.

Vectorised with pandas. Load bars into a DataFrame, compute indicators as columns, generate signals as a column of 1s and 0s, shift the signal by one bar, multiply by returns, and sum. Fast, transparent, and excellent for first-pass tests of simple rules on daily bars. Its weakness is that it does not naturally model orders: stops, limits, partial fills and gap fills all require extra logic that is easy to get wrong, and position sizing from the stop is awkward in pure vector form.

Event-driven frameworks. Libraries such as backtrader process one bar at a time and simulate a broker: orders are submitted, filled according to rules, and positions tracked. This is slower but matches how trading actually happens, and it makes stops, limits and sizing natural. The fill logic is in the library's broker simulation, so read it: the defaults for whether a stop can fill on the entry bar, how limit touches are treated, and whether slippage is applied are exactly the questions from Module 4.

Vectorised with order modelling. vectorbt sits between the two, running vectorised computations across many parameter combinations at once while still modelling entries, exits, stops and fees. It is well suited to the sensitivity tables in Module 6, because it can evaluate thousands of parameter sets quickly. That speed is also its risk: it makes it very easy to run the multiple-testing problem at scale.

A minimal reproducibility habit: whatever library you use, produce a trade list with entry date, entry price, exit date, exit price, stop, and R, and reconcile a handful of trades against the chart by hand. The spreadsheet from Lesson 1 is the reference implementation; the code should reproduce its trade list exactly before you trust it on anything more complex.

Desktop trading platforms

NinjaTrader and Sierra Chart are Windows platforms popular with futures traders. Both include a strategy engine, historical and replay testing, and connection to live brokers, so the same code that backtests can trade. Their strengths are futures-specific: correct handling of contract months and rolls, tick data, and session templates. NinjaTrader strategies are written in C#; Sierra Chart uses C++ (ACSIL) or its built-in spreadsheet-style system. Both let you configure fill assumptions and slippage; both default to settings you should review before the first run.

The advantage of a platform that both tests and trades is that the live execution path is the same code. The disadvantage is that the backtest engine's assumptions are less visible than in a spreadsheet, and the "it backtested fine on the platform" claim carries all the weight of that engine's defaults.

Commercial and hosted tools

• MultiCharts, TradeStation and Amibroker are established desktop products with their own scripting languages, portfolio-level testing, walk-forward optimisation and Monte Carlo built in. They are more expensive, more capable, and just as easy to misuse.
• QuantConnect is a hosted platform providing data and an event-driven engine (Python or C#) for stocks, futures, forex and crypto, with the data-handling problems of Module 2 largely solved for you. The cost is learning the framework and accepting its data and fill models.
• Various web-based "no-code" backtesters exist. Treat them exactly as the TradingView tester: find the commission, slippage and fill settings before believing anything.

Key idea: Every tool has a fill model, a cost model and a data model. Your job with any of them is to find those three, set them to match Modules 2 and 4, and reconcile a sample of trades by hand. A tool you cannot do that with is a tool whose results you cannot interpret.

Choosing

If you trade daily bars on a few instruments and do not program, use a spreadsheet. If you want to see results on a chart quickly, use TradingView and then export. If you want sensitivity tables, walk-forward and Monte Carlo without paying for them, learn enough Python to run one of the frameworks. If you trade futures intraday and want backtest and live in one place, look at the desktop platforms. Whatever you choose, keep the spreadsheet trade list as the ground truth that the tool must match.

Try it: Take the trade list from your spreadsheet backtest and reproduce it in one other tool: TradingView, a Python script, or a platform. Compare trade by trade. Every difference is a fill, cost or data assumption that one of the tools is making and the other is not. Write down which, and which one is right.

Recap

• Python: pandas for vectorised first passes, event-driven frameworks for realistic orders, vectorbt-style tools for parameter grids.
• Desktop platforms (NinjaTrader, Sierra Chart) handle futures data well and trade the same code live; review their fill defaults.
• Commercial tools add walk-forward and Monte Carlo out of the box; hosted platforms solve data handling at the cost of learning a framework.
• Every tool has a fill, cost and data model; locate all three before reading results.
• Keep a hand-checked spreadsheet trade list as the reference every tool must reproduce.