|
PureBytes Links
Trading Reference Links
|
Alex,
So with all the problems in TS and in WL3, have you written your own
complete program with interface and programming language that has
overcome the flaws in Easylanguage and WL's pascal type language? Or
are you actively working with current developers (on say the WL site or
TS World) to resolve many of the missing or innacurate features? I'm
guessing you don't use either program because they have so many
problems...so I'm intrigued what program you would recommend?
Regards,
Adrian
> -----Original Message-----
> From: unicorn@xxxxxxxxx [mailto:unicorn@xxxxxxxxx] On Behalf
> Of Alex Matulich
> Sent: Friday, 7 May 2004 2:00 PM
> To: omega-list@xxxxxxxxxx
> Subject: Re: AW: To MarkBrown: Real-time datafeeds in Python
>
>
> >...and then you discovered Wealth-Lab Developer 3.0 ... :)
> >
> >With all respect most of it is taken care of in WLD3.
>
> I know, Volker. WLD3 will do just most of everything I
> listed. The marks I have against it are:
>
> 1. The programming language seems to encourage people to
> write rather obfuscated and unclear code, from looking at
> some samples on the web site. You can do that in EL too, but
> I don't see it as much. I'm well versed in C, C++, Java, and
> other languages, and frankly, even though I can appreciate
> the thought that went into the design of WealthScript,
> looking at WealthScript code still turns me off. Even after
> reading through the language documentation, a lot of code I
> see still isn't clear. Some of it has to do with cryptic
> things embedded in code I see, some of it has to do with
> low-level maintenance of data streams that programmers must
> do, and some of it is just clutter (e.g. having to spell out
> long words instead of using standard aliases like H, L, C, etc).
>
> 2. WL's inability to re-calculate indicators on every tick,
> instead of at the end of each bar, also limit its usefulness
> for real-time trading. In fairness, TS can't do this with
> strategies either, but can do it with indicators.
>
> 3. Plus a couple of the others below (for example, complex math).
>
> -Alex
>
> >-----Ursprüngliche Nachricht-----
> >Von: unicorn@xxxxxxxxx [mailto:unicorn@xxxxxxxxx] Im Auftrag
> von Alex
> >Matulich
> >Gesendet: Donnerstag, 6. Mai 2004 16:49
> >An: omega-list@xxxxxxxxxx
> >Betreff: Re: To MarkBrown: Real-time datafeeds in Python
> >
> >Cameron,
> >
> >>re ... "It would be interesting to know what you could not do in
> >>TradeStation or QuantStudio that prompted you to undertake such a
> >>major effort."
> >>
> >>i havent found anything i cant do in tradestation ...[ some things
> >>werent easy but they werent imposible ......yet ].
> >
> >Good heavens, from my first month or two of using tradestation I
> >identified a bunch of stuff I couldn't do:
> >
> >== Backtesting of portfolios -- the single biggest weakness of TS
> >
> >== Optimizing against any result *I* define, not canned results like
> > net profit
> >
> >== Executing trades on ANY price data stream, not just data1
> >
> >== Backtesting of spreads determined by rules on the fly, between
> > several data streams (i.e. you can't predefine the "spread data")
> >
> >== Plotting indicators from strategies
> >
> >== Double precision data types and double precision math
> >
> >== Complex number data types, and complex math operators (not using
> > user function calls)
> >
> >== Data structures (makes passing groups of variables back and forth
> > between functions a lot easier, especially if you have an array of
> > groups of variables)
> >
> >== Structured programming, including organizing my code into logical
> > directories
> >
> >== No decent way to break out of the middle of a loop (even a 'goto'
> > statement would be useful for this)
> >
> >== No way to operate on characters within strings
> >
> >== No backtesting of combinations things displayed in different
> > charting windows (you can do this in real time with PushPop DLL,
> > but backtesting DOES NOT work with PushPop due to TradeStation
> > not calculating each indicator in a synchronized way)
> >
> >== Reliable pass-by-reference operations in function parameters
> > (you never know when it won't work; i.e. a passed-by-reference
> > parameter that changes within a function doesn't change in the
> > calling procedure -- seems to be more reliable if all NumericRefs
> > are in the beginning of the parameter list)
> >
> >... and so on.
>
|