|
PureBytes Links
Trading Reference Links
|
> > 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.
I've used vi and make for 20 years -- in fact vi is still my
preferred editor for most text, sure wish I could hook Vim into the
Power Editor!! -- but you're a stronger man than I if you want to use
vi/make on a large project instead of a more-integrated IDE. Yes, it
can work, just like Perl can work. Is it an efficient use of my time
and energy? I don't think so, but that's just my preference. If I
was familiar enough with Perl to feel its benefits outweighed C++ (or
whatever) enough to justify the weaker environment, I might choose
differently.
(Also I suspect a trading platform would end up with a lot more than
10k lines, but maybe I'm not giving Perl enough credit. What kind of
app did you write with 10k lines of Perl?)
Even an EMACS-based IDE could streamline the process a bit, but I've
never been an "EMACS is the best answer for all problems" kinda guy.
> The data never seems to come faster than 10 tics per second
FWIW with just ES and NQ, 600 ticks per minute is very common.
Obviously some seconds in the minute are going to have more than 10
ticks. And that's in normal market conditions. I suspect in a fast
market you could see at least 2x the normal tick rate, maybe 5x or
more for a few seconds. Now add in additional symbols to track, and
volume growth over time (especially with electronic markets), and I
wouldn't consider anything that topped out at anything under 50
ticks/second. 100 would be better. If you wanted to trade active
NASDAQ stocks, I doubt 100/sec would do it even in normal markets.
> I have not had a problem with GC, though depending on the
> application I know that can be a problem.
I'm curious, what LISPs have you used? I haven't done much with LISP
since the heady "AI machine" days with the Xerox & other specialized
hardware. I never worked much on those, but used several 68xxx-based
systems. GC in those days could lock up your application for 20-30
seconds, which would obviously put a kink in realtime applications.
:-) But that was over 15 years ago, and I'm sure the technology has
improved.
> 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.
Agreed. (But you give EL too much credit. It doesn't figure out how
much data to keep around -- it just keeps everything for the
MaxBarsBack period.) That's why I said ANY non-EL language is going
to have to write a lot of infrastructure.
As I said, I'd be leery of LISP or Perl. Java is a possibility,
though I'm not convinced of Java's robustness. Not sure how well it
handles large databases or realtime calculations. (Though the
platform independence would be a big win.) I *know* C++ can handle
that, and I bet VB can too.
> With a translator to convert EL to something else,
I agree with Bob B. It would be much safer, and probably cheaper in
the long run (especially when you factor in the cost of mistakes :-)
to just rewrite it in the new environment.
Gary
|