|
PureBytes Links
Trading Reference Links
|
PS: This is perfect example of why it's better to use prorgams that are
written by the largest companies and used by the most users. You get more
reliability, more stability, less hassle, more compatibility, and an overall
higher probablity that the company won't suddenly buckle under and sail off
into the sunset leaving you high and dry.
B.
-----Original Message-----
From: Brian Massey [mailto:bnm03@xxxxxxx]
Sent: Wednesday, October 28, 1998 10:27 PM
To: List, Omega
Subject: RE: Pierre's EL vs VB
Would-be EL programmers are way better off learning VB anyway. Not only
will they be able to produce systems faster and more reliably in VB than in
EL but their knowledge of progamming will not be limited to just stupid EL
programming. They'll be positioned to start writing really cool things like
Active X controls, DLL's, COM interfaces, Internet programming and the like.
They wil be able to take their knowledge of BASIC and write full blown
windows applications. The investment learning to write systems in VB will
pay off a hundred fold more times than learning an isolated, specific and
questionable language like EL by a company like Omega.
B.
-----Original Message-----
From: Alain JOSSART [mailto:Alain.Jossart@xxxxxxxxxx]
Sent: Wednesday, October 28, 1998 10:06 PM
To: omega-list@xxxxxxxxxx
Subject: Re: Pierre's EL vs VB
Pierre,
My comment is possibly the most achieved garbage ever written, never
forget to remove the modem cable before smoking the carpet, however...
It was not pretending that you have written a bad EL optimization, just
that you didn't even consider that "optimization" could be qualified
"complication" when looked at with non Omega glasses.
Say, if VB (or even a TA language like FlexSoft TAS) can already formulate
your very elementary sample more directly in the simplest and most efficient
manner, how is your illustration supposed to be supportive of the completely
arbitrary stance that : "VB will not be more suitable because it has more
power,
and EL is already complex for the trader".
The only demonstration you provided is that EL is a questionable trader
programming language.
The rest has no substance. It's a one line technical magazine article
containing : " The editor's choice is EL ! VB is too powerful then to
complex.
Period.". Very valuable, thanks.
All in all, it was possibly the worst idea to even pay attention to one more
magistral prof stance... with no proof
-- Alain
_____________________________________________
>Date: Tue, 27 Oct 1998 10:00:04 EST
>From: Orphelin@xxxxxxx
>To: Omega-list <Omega-list@xxxxxxxxxx>
>Subject: Re: Where's the Board???
<>
>My purpose was to demonstrate that people able to do such mistakes with
Easy
>language will certainly do bigger mistakes with Visual Basic, that has MORE
>features than EL, so more reasons to write stupid code.
>VB has more power than EL has.
>Period.
>This is not a proof that an average EL user will use it with benefit.
>
>Despite that fact that you are a programmer, you do not master EL to write
an
>adequate comment in this case.
>The benefit was not to reduce there lines into 2, but:
>
>-To avoid 1 momentum calculation ( a price difference).
>-To avoid to store intermediate calculation in value1 and value2, because
>previous values of c-c[1] are already stored in the maxbars back array, and
I
>only refer to the previous values of TWO variable instead of THREE.
>
>> I'm sure most of use do remember the good old times when PC BASIC
>> was an interpreted language on 1000x slower PC's and programmers
>> were judged based on their capabilities to write the shortest possible
>> code. I've beaten them all hands down :
>>
>> A=c-c[3];B=.03*(A-A[1])+.97*B;
>>
>
>This solution is valid too.
>It's the solution that I posted!!!
>You have just changed the same of variables into A et B ( this do not spare
EL
>TOK code), and concatened it into a single line.
>The lenght of the compiled code will be the same!!!!
>
>More, it will not work because "A" used as a variable name is an EL skip
word
>that will not verify in Easy language!
>
>> Nice EL code, but are you convinced ? - Where is the demonstration
>> that, once compiled, it is certainly faster than a compiled :
>>
>> VALUE1 = @MOMENTUM(C,3);
>> VALUE2 = @MOMENTUM(C,3)[1];
>> VALUE3 = .03*(VALUE1-VALUE2)+(1-.03)*VALUE3;
>>
>> The truth is not there ! The kind of optimization games doesn't make
>> any sense for a modern programmer... they should even less for
>> a trader.
>
>Read my post again.
>It was only a simple example posted to this list.
>
>The problem is not the language in itself, but more the user of the
language
>and its own knowledge of it.
>Thanks for your demonstration. It's the prof that I was right:
>
>You failed yourself in your demonstration, live!
|