Пожелания к синтаксису языка MQL - страница 10

Новый комментарий
 
Забавно все это читать. Вспоминаю вопли старых товарищей, когда решили в MQL ввести классы, "указатели" и структуры. Так и писали: "Вы убили MQL! Теперь на нем смогут писать только профи..." - ну и прочий бред. Теперь вопли с другой стороны: дайте полноценный С++, а то мега систему невозможно закодить. Но кто вам всем мешает? Берите С++ и в путь. MQL это немного другая история, и путать теплое с длинным как-то наивно.
 

Да что вы заладили про С++…  Ну не нравится вам С++, так возьмите C#.  Я же специально упоминал его и в исходном посте, и дальше в обсуждениях подчёркивал это.  Многое из предложенного касается обоих языков.

Поэтому тут одно из двух:  либо вы против прогресса в принципе, либо просто побрюзжать.  Хотя оба варианта тоже возможны

 
Alexey Navoykov:

...

MetaTrader хороший терминал. Но к сожалению, подавляющее большинство его пользователей так и остались лудоманами и гэмблерами. MQ приложило очень большие усилия для перемещения в нишу интеллектуальной торговли, но у нее не получилось. Гэмблерам достаточно "тыркалки" МТ4 с каким-нибудь разноцветным "ТрендЛазером" напяленым на чарт. Им пофиг на структуры, классы, изыски с decltype и пр. пр.  Но с "худой овцы хоть шерсти клок" - так и живем. Поэтому в сложившихся ситуации, развивать языковые средства MQL5 экономически нецелесообразно. А целесообразно заигрывание с толпой, например введение локов на МТ5 или появление Open[0] вместо CopyRates.

 

Вообще, немного странно получается. Изначально, MQL создавался как прикладной язык для написания торговых стратегий. Поэтому, в него не добавили все, что есть в С++. И наверное, хорошо.  Но с течением времени, задачи в алготрейдинге усложнились и люди ищут и ждут дополнения к языку. Таким образом, они стремятся поместить в него все, что было намеренно в него не добавлено. При этом, количество правил и уровень сложности языка выростет, становясь барьером для них самих. Но, если они готовы их преодолевать, их не остановишь. 

Для меня, разработка - это в первую очередь, нахождение самого верного и простого способа реализации мысли. Если исходить из этого, то возможностей старого языка вполне хватает, но профессиональные программисты чуствуют ностальгию по куче правил и нагромождению синтаксиса. )) Ну, если это дает им вдохновение, - почему бы и нет?

 
Реter Konow:

 При этом, количество правил и уровень сложности языка выростет, становясь барьером для них самих.

Почему барьером то?  Добавление новых возможностей не препятствует использованию старых. Как правило.  Поэтому никто не заставляет пользоваться этими "сложностями".

Хотя конечно были периоды, когда устаканившиеся правила вдруг нещадно перекраивались в угоду С++, но то было время стремительного развития языка.  Сейчас то почти всё уже есть,  остались небольшие доработки. 

 

Кстати, лично я за последние полтора года ощущаю не только отсутствие улучшений, а ещё и урезание возможностей языка.  Наиболее функциональный и стабильный билд был 1554 от 14 марта 2017.  После которого произошла какая-то кардинальная переделка внутренностей, и пошли проблемные билды с кучей багов, некоторые из которых не пофиксены по сей день.  Правда были исправлены некоторые из старых багов.  В общем по уровню багов нынешние билды наверно чуть выигрывают.  Но вот насчёт функционала...

Например, я уже писал про урезание возможности приведения массивов к базовым типам.  Ещё одним урезанием был запрет на приведение простых структур друг к другу.  Да, взамен дали юнионы, но они не покрывают тех возможностей, которые давало приведение, позволявшее восполнить недостатки штатного функционала.   А именно, оно позволяло производить полиморфизм структур.  Ввиду отсутствия в MQL интерфейсов для структур (о чём я уже писал), данное решение было хорошей альтернативой.  Вот примерно так:

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:

Почему барьером то?  Добавление новых возможностей не препятствует использованию старых. Как правило.  Поэтому никто не заставляет пользоваться этими "сложностями".

Хотя конечно были периоды, когда устаканившиеся правила вдруг нещадно перекраивались в угоду С++, но то было время стремительного развития языка.  Сейчас то почти всё уже есть,  остались небольшие доработки. 

Я имел ввиду, барьер для тех, кто сам хочет использовать новые правила и синтаксис по собственному желанию. Им придется дольше писать свои программы и дольше в них разбираться. Станут ли от этого их программы эффективнее? - не факт. Смогут ли они решить большее количество задач? - не факт. 

Однажды на форуме я предложил очень простое решение задачи, которую все решали с помощью "горы" кода. Оно было маленьким и быстрым. Однако, оно всем непонравилось. Там небыло того, что они любят. Всяких template<typename T>  и  void Func(IValueable<A> &a)

Мне предлогалось все это использовть. На вопрос "зачем?",  никто ничего внятно не объяснил.


P.S. Наиболее ясное объяснение, которое я получил, - "Ваш код некрасив". И еще : "Вы не понимаете концептуальную мощь". Но я разработчик. Мне нужно красивое решение, а не красивый код.

 
Alexey Navoykov:

запрет на приведение простых структур друг к другу.  Да, взамен дали юнионы, но они не покрывают тех возможностей, которые давало приведение, позволявшее восполнить недостатки штатного функционала.   А именно, оно позволяло производить полиморфизм структур.  Ввиду отсутствия в MQL интерфейсов для структур (о чём я уже писал), данное решение было хорошей альтернативой.  Вот примерно так:

Это компилируется

#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; }
};

Но результат, конечно, другой.

1...345678910
Новый комментарий