Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
i agree with @traderwerks - some ppl jump prematurely.
for those who like to program at the lowest possible level and create their own abstraction layer, unmanaged can be leveraged to generate more reusable code blocks with fewer lines. win-win!
Going unmanaged requires a lot of work upfront. A simple example would be SetStopLoss(). The plumbing work is done in managed mode so that a user can simply call the method without much thought of it. In Unmanaged mode, one has to write the code that handles the low-level management of stoploss orders.
Another factor to consider is that unit-testing of error-handling code in NT is not easy. This will limit the complexity of code an individual trader can accomplish. From time to time, I have to remind myself that I am a trader, not a software developer.
I don't think it's so different for stop loss, as an example. Issuing the stop loss is one call, and the extra thing is just cancelling it when the position is closed (and even that is automatic if you OCO it with an exit)
I'm not sure that's so different between managed and unmanaged. Much error handling still has to be covered in both approaches.
Recent posts have suggested that some people may go to unmanaged too soon. Do you have an example of that where it's turned out to be a bad thing? OK, if you're not a decent programmer, don't do it, but I would have thought a well written unmanaged library would usually be preferable to using the managed orders. The difference in the strategy itself is minimal.
(As an aside, if you're writing the unmanaged stuff in your strategy and not doing some sort of reusable blocks I would have thought it very likely that unmanaged is not for you)
We are talking about the same thing. Your unmanaged code will have to track the change of position. Adding to that you have profit targets, it is some work. The coding probably will take about a couple of hours, but the testing and covering of rare cases like overfill, rejected orders, would take weeks (and I talked about the difficulty of unit-testing in NT environment, which makes it an even more difficult job). You would want to complete the test before you can use even a basic feature like Stoploss. Bugs, in this kind of software, can cost big money, your money.
In a managed environment, most of the work (coding, testing of position/order tracking) is done. That makes a difference in terms of how much confidence you put on the code.
Agreed. I was referring to the unit-testing of extra working associated with unmanaged code, such as basic position/order tracking.
Unmanaged approach offers much more flexibility, but we have to weave our own safety net and that takes time and patience because one will not see any progress in trading system development while doing the plumbing work, although it is necessary if the unmanaged path is chosen.
Yes, you are right. The default error handling behavior is the same so it makes no difference whether you use managed or unmanaged.
I mentioned about profit target because it is a basic feature for many traders. If you do not use profit targets at all, then it is irrelevant. If you do, sooner or later you will have to add it in. Then the stoploss-handling code and profit target-handling code would become highly coupled and difficult to debug because they have that OCO-kind of relationship. OCO orders appear to be the answer. However, when I was thinking about the architecture, OCO orders did not seem to be a good solution to the problem if I plan to reuse the code in many of my strategies. But I can be wrong.
I meant profit target is irrelevent if we're just comparing stop loss.
I don't see the problem with OCO for this, esp when you could have the strat set a flag to turn OCO on/off. However, the way I have designed my library, I don't see this as a problem without OCO too. Each type of order has a var name, and I always call my own library OnExecution, so it's always just
if execution is profit and stop is working/pending
cancel stop