This is from a friend of mine that has played with Ninja far more than I have:
Hi LP, these are just my first impressions. There are some things about the interface that could be made smoother. Like, on TS I can drag indicators around with the mouse, and seem to have more control over how they are scaled, and how scales are combined.
1) In TS, you can provide arbitrary formulas as inputs… so I can make an indicator with 2 inputs and feed it (Close*0.5) and MedianPrice. In Ninja, it appears your inputs are limited to numbers and bools. So, for some indicators I’d have to devise a “input 1 for Close, 2 for MedianPrice, 3 for …” At least they let you chose one price “Input[]” from the configuration screen. But, that’s just one, and you have to hope the indicator is written to use Input[] rather than Close[].
2) While c# is way more modern and powerful than easylanguage, there is something to be said for a more custom language:
In TS, their language engine can usually figure out how many bars of data you need to reference, and set you up accordingly. In Ninja, you get exceptions if you don’t manage how many bars of history are available manually.
3) In TS, all variables you use can transparently support historical references. In ninja, you must make IDataSeries containers for past data you want to reference.
4) TS and ninja both pollute a global namespace. I was hopeful that ninja would use C# to improve on TS this way, but they didn’t. Ninja inserts wrapper code around your indicators to force them all into the same namespace (as functions in the same base class). I think they could have used reflection to keep the names separated.
Hi LP, these are just my first impressions. There are some things about the interface that could be made smoother. Like, on TS I can drag indicators around with the mouse, and seem to have more control over how they are scaled, and how scales are combined.
1) In TS, you can provide arbitrary formulas as inputs… so I can make an indicator with 2 inputs and feed it (Close*0.5) and MedianPrice. In Ninja, it appears your inputs are limited to numbers and bools. So, for some indicators I’d have to devise a “input 1 for Close, 2 for MedianPrice, 3 for …” At least they let you chose one price “Input[]” from the configuration screen. But, that’s just one, and you have to hope the indicator is written to use Input[] rather than Close[].
2) While c# is way more modern and powerful than easylanguage, there is something to be said for a more custom language:
In TS, their language engine can usually figure out how many bars of data you need to reference, and set you up accordingly. In Ninja, you get exceptions if you don’t manage how many bars of history are available manually.
3) In TS, all variables you use can transparently support historical references. In ninja, you must make IDataSeries containers for past data you want to reference.
4) TS and ninja both pollute a global namespace. I was hopeful that ninja would use C# to improve on TS this way, but they didn’t. Ninja inserts wrapper code around your indicators to force them all into the same namespace (as functions in the same base class). I think they could have used reflection to keep the names separated.
Comment