Quote from fullautotrading:
As a general premise, I have some general personal reservations for designs where one expects people just plug in strategies into his program to be executed. What would be the benefit ? If they can code at that level, they would just directly route to the broker or the exchange, with much greater flexibility. But i might be wrong on this (personal opinion) and I like to hear different views.
If a user can code the whole "platform", it doesn't necessarily mean that this us where the "payout" is the highest. Like you point in your earlier post, a user could start with coding a text editor... but this isn't where added value is.
The reasons to use an existing platform are to take advantage of (in no particular order):
1) Support for market interface. A few brokers change their API often. Here the makler of the "platform" will take care of any changes and the user will have to apply a patch at some point. Saves some time that can go towards making a profitable strategy.
2) Collecting and saving market data. Hopefully, the "plaform" creators gave it some thought so that this part doens't lag horribly when market activity increases. Can be done but this where sloppy code can really backfire. Happened on earlier version of NinjaTrader.
3) Doing "housekeeping" with orders. Maintaining list of open orders, cancelling them in some systematic way when needed, calculating position, making sure any order placed wouldn't increase position beyoned the desired maximum size. The next level of "housekeeping" may include making sure that ordrs marked as "exit position" are never placed unless the system has a position to close; or not placing a stop order in the market price is sufficiently close to stop price (may dramatically reduce order modifications with the broker). This second level of "housekeeping" lets the actual trading strategy contain less code that is not relevant to the logic of the strategy.4) Backtesting. Yes, writing a simple backtester is not a huge task. Moreover, a purpoise-built backtester will probably be massively faster than most out-of-the-shelf backtesters due to not having all the unnecessary "fat" like creating order objects. However, adding bells and whistles to it is not a small task. Using out-of-the-shelf one frees more time to work on the logic of the trading strategy.
5) A good backtester-simulator helps test order-handling logic. Are partial fills and rejected order handled appropriately? Are delays in order placement taken into account? etc
All of the above are doabe for someone with decent programming experience and understanding of pitfalls in market dat acollection and backtesting. The question is whether a person wants to create all of the above (spending perhaps a few years as a lone developer) or whether he/she wants to concentrate on finding and improving profitable trading ideas.
Another aspect is testing. The features are likely to contain a few bugs. A platform used by a few thousand users rather than one user will hopefully have most serious bugs fixed fast as people may give heavy use to different parts of the platform and report problems. On the other hand, when a problem is found the only thing a user can do is to pleed with the developers to fix it, However serious the problem is or however trivila the required fix is it will be up to the developers when to fix it and whether to fix it at all. A "home-made" platfrom can be fixed by the user himself at the earliest convenience.
Quote from fullautotrading:
In any case, if one has to code, he would like to (to be able to) use VB.net and C#, for sure (i.e., the modern "non-masochistic" languages). Therefore the host application must be able to perform on the fly .net compilation of user's programs.
Haha! I like how you call C++ "masochistic". Just last night I spent over an hour finding out that a reference to an object was becoming invalid due to the object being moved to a new location (by copying). This is something that would never happen in C# or Java.
Quote from fullautotrading:
As to design compatible with profitability, there are naturally many ways to create "systematic unprofitability" by design (it's clearly easier to create unprofitable frameworks). An example could be a trading engine which restricts the user to "strategies" having the following "structure":
Compute realtime one or more user (statistically predictive) "indicators", say V1, ..., VK
Make an Entry when a given condition, function of the indicator occurs.
Make an Exit (possibly with a trailing stop) after a target profit is reached, or when a given loss threshold is reached.
This would typically generate beautiful results and equity curves in backtesting ("curve fitting"), but substantial losses in live trading in the long term.
Tom
When you mentioned platforms incompatible with profitability I thought you were talking of fatal flaws in order handling or forward looking bias in backtesting.
For example of forward-looking, a few people assume that they can use the closing price in generating a signal and execute on the same closing price. That's a very strong assumption for a backetst. A more reasonable one would be executing on the next open price.
Tom, in your post you basically say: A trading strategy has an entry signal and an exit signal. How can a strategy work in a different way?
