Less code, more action... writing an EA - page 2

New comment
 
Maxim Kuznetsov:

the use-case style is fundamentally procedural, as it is the most common. Potential users(novice programmers) write in this way.

What I mean is that your style is procedural in essence. That is, it is procedural both inside and outside, with all the resulting problems. At the user level, you can't disclose implementation details as a matter of principle. And you have a very specific thing going on in your code at the user level:

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

Conditional compilation macros, calls of specific MA function implementations, etc., etc. I.e. not OOP, not FP, but this kind of matte procedural programming. And as the cherry on the cake: ea.Symbol, i.e. formally, it is still OOP.

 
Maxim Kuznetsov:

I'll try (or will try, if interested) to make a basis for EAs.

The result will be as useless (for most people) as all those mentioned in the thread.

because you immediately try to write in your own way rather than well. just like the authors of all those mentioned.

 
Vasiliy Sokolov:

I mean that your style is procedural in nature. That is, it is procedural both internally and externally, with all the problems that come with it. At the user level, the details of the implementation cannot be disclosed in principle. And you have a very specific thing going on in your code at the user level:

Conditional compilation macros, calls of specific MA function implementations, etc., etc. I.e. not OOP, not FP, but this kind of matte procedural programming. And as the cherry on the cake: ea.Symbol, i.e. formally it's still OOP.

Once again, use-case is written from the presumed point of view of potential users.

But to a sufficient extent to be able to proceed to the library without touching the use-case itself.

We have to use conditional compilation, because both 4 and 5 are in the forum.


 
Maxim Kuznetsov:

Once again, use-case is written from the presumed perspective of potential users.

To rephrase: where is the procedural style requirement to insert calls of specific platform-dependent functions like iMA(...)?

Maxim Kuznetsov:

But in sufficient volume to allow one to start the library without touching the use-case itself.

How can we do that when use-case is full of specific calls of platform-dependent functions?

Maxim Kuznetsov:

You have to use conditional compilation because there are both 4 and 5 in the forum.

So user-case level "universal code" cannot even be platform-independent?

 
Maxim Kuznetsov:

...

If we're talking about user-case - commandment number one: no specific implementations at this level. But at user-case level you already have full dependence on: 1) platform, 2) API of the terminal. I.e. the proposed implementation is completely inconsistent with the stated concept.

 
Vasiliy Sokolov:

If we're talking about user-case - commandment number one: no specific implementations at this level. At user-case level, you already have complete dependence on: 1) platform, 2) terminal API. I.e. the suggested implementation completely doesn't correspond to the stated concept.

In general, the developers write in MQL, and for the API of the trading terminals MT4, MT5 :-) Therefore, the use of the API terminal is normal.

The use-case should demonstrate/do the typical things for the area. Not just add a couple of numbers, but have an understandable purpose for the user, the one we want to achieve. The minimal possible purpose of Expert Advisors is trading :-) The simplest Expert Advisor that I can think of is to trade on crossover averages. It is given in full in the source post.

By the way, it works. At this very moment instead of trading functions stubs and checkmarks are being drawn :-) I'm writing/debugging the data. As soon as the part with data, though crude, but ready for discussion - I will post it


 
Maxim Kuznetsov:

You generally write in MQL and API of MT4,MT5 trading terminals:-) so referring to the API terminal is normal.

The use-case should demonstrate/do the typical things for the field. Don't just add a couple of numbers, but have a user understandable goal, the one we want to achieve. The minimal possible purpose of Expert Advisors is trading :-) The simplest Expert Advisor that I can think of is to trade on crossover averages. It is given in full in the source post

And by the way it works. At the moment I am writing/debugging data instead of trading functions and drawing ticks :-). As soon as part with data, though raw, but will be ready for discussion - I'll post it also

You write it correctly. But the user understands such pseudocode much better:

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

Another thing is that to make it work in this form (procedural, I note) is very difficult, but it's still possible. This is what one should try to achieve - make the user-level instructions as simple and abstract as possible. But in your code, the user has to specify conditional compilation macros, specific functions for calculating averages and other technical details which he simply cannot handle.

 
Vasiliy Sokolov:

To rephrase: where does procedural style have a requirement to insert calls to specific platform-dependent functions like iMA(...)?

How untouchable, if use-case is replete with specific platform-dependent function calls?

So user-case level "universal code" can't even be platform-independent?

4/5 platforms have different API's, it just so happens.

I'm not writing another layer of compatibility for everything, or a universal library. As much as I don't want to :-)

only the basis for EAs.

 
Vasiliy Sokolov:

Well, you write it correctly. But the user understands such pseudocode much better:

Another thing is that it's much harder to make it work in this particular form (procedural, I notice), but still it's possible. This is what one should try to achieve - make the user-level instructions as simple and abstract as possible. But in your code, the user needs to specify conditional compilation macros, specific functions for calculating averages and other technical details he simply cannot handle.

In principle, you can use an entry like the one you cited inside GetData OnCrossSignal. Potentially, you can even write scripts :-) But all in good time... Data handling is built as an electronic table.

 
Maxim Kuznetsov:

4/5 platforms have different API's, that's just the way it is.

I'm not writing another compatibility layer for everything, or a universal library. As much as I don't want to :-)

only the basis for EAs.

Look at Artem's code. His code has one single API, which is independent of the target platform. That's why the argument that "it works that way" is strange to hear.

12345678910
New comment