|
PureBytes Links
Trading Reference Links
|
On Thu, 31 Jan 2002, Gary Fritz wrote:
> > I disagree about EL not being a language for trading. The syntatic
> > sugar designed into EL is what allows it to be so easy in
> > indicators and functions for financial purposes.
>
> I don't agree. I don't think "buy at BuyPrice stop;" is all THAT
> much easier than "buyStop(BuyPrice);". On the other hand,
> automagical management of access to recent values of any variables,
> price values, etc, is basically invisible to the syntax (other than
> the [] notation) but provides critical EL functionality.
>
> > Perl, lisp, and java would be easier than c++ or vb due to the way
> > it handles memory management and recovery.
>
> I haven't seen a LISP I would trust with realtime trading, especially
> for designing a large trading platform application, but maybe LISPs
> have come a long way since the last time I used them. Hopefully they
> manage garbage collection a lot more transparently than they used to.
>
> I know it's a personal preference, but I've never felt Perl to be a
> very good language for developing large applications. The whole
> language seems more concerned about minimizing the characters it
> takes to implement any particular functionality, and providing
> sixteen obscure ways to do any particular feature, than in helping
> you to develop reliable software. Are there any good IDE's for Perl
> or are you stuck with a text editor and "perl -w" ?
The ide I use is vi and make. It has worked for applications that are
near 10K lines. Lisp would be as good at the near-real-time of TS
as anything might. The data never seems to come faster than 10 tics
per second and certainly any lisp can handle that load. If you
combine the application with either a native compiler or with
byte-code compilation, your speeds get faster. I have not had a
problem with GC, though depending on the application I know that can
be a problem.
What EL does for the code is more than the [] syntax. Depending on
the function the EL system will attempt to determine how many
days of data to look at, will keep previous calculated values in
case they might be needed again, if a function is called by two
different indicators the EL system seems to keep the function
space in its own local environment and does not mix the intermediate
values. EL is a complex system and it would be difficult in several
ways to replace its implied functionality, but it is possible.
With a translator to convert EL to something else, the implied
price series manipulations and storage can be emitted with the
translated code and there by reduce some of the vagueries of
what is happening.
Mike
|