[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pierre's EL vs VB



PureBytes Links

Trading Reference Links


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!