Suggestions for MQL syntax - page 10

New comment
 
It's funny to read all this. I remember the cries of old comrades when they decided to introduce classes, "pointers" and structures into MQL. They used to write: "You have killed MQL! Now only professionals will be able to write in it...". - and other nonsense. Now they're yelling from the other side: let me have a full-featured C++ while the mega-system is impossible to code. But who prevents you all from doing that? Take C++ and go on your way. MQL is a bit another story and it's naive to mix up the warm and the cold.
 

What are you saying about C++... If you don't like C++, take C#. I specifically mentioned it in my original post and further in discussions I underlined it. Much of what was suggested concerns both languages.

So one of two things: either you are against progress in principle or just grumble. Although both variants are also possible

 
Alexey Navoykov:

...

MetaTrader is a good terminal. But unfortunately, the vast majority of its users are still losers and gamblers. MQ has made a very big effort to move into the smart trading niche, but it hasn't succeeded. The gamblers just need a "poke" MT4 with some multi-coloured "TrendLaser" on the chart. They don't care about structures, classes, specialties with decltype, etc. But "a fleecy of a thin sheep" - that's how we live. Therefore, in this situation it's not economically feasible to develop language features in MQL5. But it would be reasonable to flirt with crowd, for example introduce locks in MT5 or Open[0] instead of CopyRates.

 

Actually, this is a bit strange. Originally, MQL was created as an application language for writing trading strategies. Therefore, it didn't have everything that C++ has. But over time, tasks in algorithmic trading became more complicated, and people look for and wait for additions to the language. Thus, they tend to put everything that was intentionally not added to it. In doing so, the number of rules and the level of complexity of the language will increase, becoming a barrier to themselves. But, if they are willing to overcome them, there is no stopping them.

For me, development is first and foremost about finding the right and easiest way to implement a thought. As such, the capabilities of the old language are good enough, but professional programmers feel nostalgic for the heap of rules and piles of syntax. )) Well, if it gives them inspiration - why not?

 
Реter Konow:

At the same time, the number of rules and the level of complexity of the language will increase, becoming a barrier to them.

Why a barrier? Adding new features does not prevent them from using the old ones. As a rule, no one is forced to use these "complexities".

Although there were certainly periods when the established rules were suddenly mercilessly altered for the benefit of C++, but that was the time of its rapid development. Now the language has almost everything and only small modifications are left.

 

By the way, I personally feel not only lack of improvements, but also reduction of language features in the last year and a half. The most functional and stable build was 1554, dated March 14, 2017.After that there was some radical redesign of the internals, and there were problematic builds with a lot of bugs, some of which have not been fixed to this day. However, some of the old bugs were fixed. In general, the level of bugs current builds are probably slightly better. But about the functionality...

For example, I've already written about cutting the possibility to cast arrays to basic types. Another cutting was a ban on casting simple structures to each other. Yes, they were replaced with units but they don't cover the possibilities given by the cast which allowed to compensate the drawbacks of the regular functionality. Given that MQL has no interfaces for structures (I've already written about it), this solution was a good alternative:

template<typename T>
struct IValueable
{ 
  double Value() const { return ((T)this).GetValue(); }
 protected:
  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

  A(double value) { _value=value; }
  
  double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print(a.Value()); }


void OnStart()
{
  A a(10);
  Func(a);
}
 
Alexey Navoykov:

Why a barrier? Adding new features does not prevent you from using old ones. As a rule, no one is forced to use these "complexities".

Although of course there were times when well-established rules were suddenly mercilessly rewritten for the sake of C++, but that was the time of its rapid development. Now we have almost everything and only little modifications are left.

I meant a barrier for those who want to use the new rules and syntax on their own. They will have to write their programs longer and take longer to understand them. Will this make their programs more efficient? - Not really. Will they be able to solve a larger number of tasks? - Not really.

I once suggested on a forum a very simple solution of a task that everyone used to solve with a mountain of code. It was small and fast. However, everyone didn't like it. It didn't have those things they liked. All sorts oftemplates<typename T> andvoid Func(IValueable<A> &a)

I was offered to use them all. When I asked "why?" nobody explained anything clear.


P.S. The clearest explanation I got was: "Your code is ugly". And another thing : "You don't understand the conceptual power". But I am a developer. I need a beautiful solution, not beautiful code.

 
Alexey Navoykov:

Yes, they were replaced by unions, but they do not cover the possibilities that were provided by the conversion, which allowed to make up for the shortcomings of the standard functionality. Given that MQL doesn't provide interfaces for structures (I've already written about that), this solution was a good alternative:

This compiles.

#include <TypeToBytes.mqh>

template<typename T>
struct IValueable
{ 
  uchar Tmp;
  double Value() const { return (_C(T, this)).GetValue(); }
 protected:
//  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

//  A(double value) { _value=value; }
  void Set( double value ) { _value=value; }
  
  double GetValue() const { return _value; }
};

But the result, of course, is different.

1...345678910
New comment
Reason: