[Development Record] Why the Lab Advocates Python Drive: Reasons from Development and Operations Perspectives

In the previous development log, I recorded the structural frictions that arise when porting the logic implemented in Python to MT4, specifically the mismatch in indicator calculations. This time, I want to organize the underlying question from two perspectives—development and operation—why does the lab push for Python-driven operation to such an extent? It may seem rational to complete everything in Python from the start if you only consider porting hassles, so I will articulate that reasoning again.

1. Development perspective: the value of having verification and live operation under the “same code”

The frictions documented up to now—the inconsistencies in indicator calculations across environments and the reduced reproducibility due to language differences—would not occur at all if verification through Python alone could cover both testing and live operation.

The advantages verified in testing (backtesting) would directly reflect in live operation as well. This seems obvious, yet for someone who has experienced porting to MT4, it is incredibly valuable. Considering that a large portion of development effort is actually spent not on thinking through the logic itself but on checking the reproducibility after porting, the difference is far from small. Form hypotheses, test them, and use the results to improve—whether you can run this development cycle quickly depends greatly on whether translation between environments is involved.

2. Operations perspective: capability to adapt to complex fund management and multi-strategy operation

Another reason is flexibility in the live phase. Cross-currency pairs, cross-logic capital allocation, and centralized risk management are, in Python—the universal language—much easier to design and implement.

Additionally, when issues occur, you can freely construct logging design and monitoring systems according to your own philosophy, making it easier to avoid a state of “watching without understanding what is happening.” In terms of operational transparency, Python-driven operation has clear advantages. In volatile markets or when a communication failure occurs, the ability to immediately determine where and what happened is not a negligible point from a capital preservation perspective. The time taken to pinpoint the cause of the failure directly translates into loss risk.

3. Still, the product is delivered to MT4/MT5

Reading this, you might think, “If that’s the case, isn’t Python-driven development always the right answer?” In reality, though, the vast majority of automated trading users operate their EAs in MT4/MT5 environments, and that is the audience the lab wants to serve with its products. Therefore, as noted previously, the path to productization inevitably involves porting. The ideal development environment and the target user base are not always aligned. This is a structural dilemma not only for the lab but for software development in general. If you prioritize ideals too much, you end up reaching too few, but if you cater too much to reality, you compromise the ideal quality. Balancing this tug-of-war is a test of a developer’s skill.

In other words, the lab’s stance is to pursue Python-driven development and operation as the ideal, while delivering products to MT4/MT5 as a practical necessity.

4. What you need to start Python-driven development yourself

If you are reading this and think, “I’m feeling the limitations of MT4 and want to try Python-driven development myself,” what you need can be broadly divided into three: programming skills, knowledge for integrating with broker APIs, and a self-sustaining server and infrastructure operation framework. You must build and maintain the toolset mentioned in the previous article (Python runtime environment, API integration packages, data processing libraries, VPS, monitoring mechanisms) entirely on your own.

Assembling these from scratch on your own is by no means easy. In particular, API integration and infrastructure management are areas where books or self-study alone tend to lead to dead ends and require substantial learning cost and time. Even with strong implementation skills for the logic itself, many stumble when creating a system that runs stably 24 hours a day. Given these technical hurdles, consulting with teams that specialize in verification and logic development is one option worth considering.

5. About the logic currently commercialized

Also, the logic that the lab currently offers as a product has been adapted by carefully accounting for the porting frictions described here, while confirming accuracy through forward testing. Rather than simply saying “it’s fine,” I would prefer you to look at real forward-test results when evaluating it. Not just the numbers from testing, but the performance after deployment in live operation will best reflect the porting accuracy. Substantial practical results accumulated over time are ultimately the strongest evidence for convincing potential users, more so than flashy slogans.

Semura Lab.’s view on balancing development and productization

For Semura Lab., Python-driven development represents the ideal form, and porting to MT4/MT5 is a practical choice to deliver products. These two are not inherently contradictory; they are two wheels that propel the development process. Neither pursuing the ideal nor delivering something usable should be neglected. In future development logs, I will honestly document how we balance these two aspects.