Респект и уважуха создателям языка, Но... - страница 2

Новый комментарий
 
Renat писал(а)  :

.....

Было бы хорошо иметь возможность подключать такую библиотеку. Не мной лично написанную (мне и 100 жизней не хватит), а проверенную и отлаженную.

Собирать так как это было на MQL4 не дело. Вот пример. Быстрое Преобразование Фурье klot написал https://www.mql5.com/ru/code/9696  ей уже 4 года. А споры о том работает или нет, идут до сих пор https://www.mql5.com/ru/forum/125844     и я в свое время недели 2 потратил на проверку.

Лучший вариант иметь, что то типа стандартной библиотеки (библиотек) MQL5 в которой постепенно исправлялись бы все не точности работы и постепенно добавлялись новые математические методы обработки данных с хелпом по ним (матлаб так и развивался).

 

Но все равно, мы раз за разом уменьшаем объем необходимой реакции трейдеров на изменение рыночного окружения, переделывая поведение системы в автоматический вид.

 В разы бы сократить, а не раз за разом.

 Вот такие  проекты https://www.mql5.com/ru/articles/88 считаю Вам обязательно нужно поддерживать. Я интуитивно понимаю, что там есть то, что мне нужно, но хелп… английский, тут то и на русском (родном) не с первого раза доходит

 
Renat:

Не думаю, что профессиональных программистов остановит отсутствие эксепшенов или шаблонов.

Ну а прямые ссылки никто не даст - прикладной и распространяемый (EX5) язык должен быть максимально безопасным, иначе на нем сразу надо ставить крест.

Что это за подход такой - "программистов не остановит"? Можно подумать, что задача вашей фирмы, чтобы МетаТрейдером пользовались вопреки созданным в нем неудобствам и осознанным недоработкам.

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

Ладно, с шаблонами, можно подождать, но перегрузка была бы очень полезна.

Что касается "прямых ссылок", то тут уж можно было вполне их спроектировать как яко-бы "прямые" с точки зрения скриптовика, но внутри организовывать доступ по всем правилам песочницы. Речь например о таких ужасно неудобных вещах, как разобщенные индикаторные массивы. У меня куча индюков, в которых приходится писать целую простыню настройки буферов - каждого отдельно, хотя можно было бы сделать это в коротком цикле, если бы, например, допускалось заносить "ссылки" на массивы в массивы. Это не только вопрос сокращения формы записи, но и ликвидация кучи потенциальных ошибок, которые у любого скриптовика случались уже не раз.

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

 

В общем, обобщенный призыв "сделайте программирование простым". Но такого не бывает.

Работа разработчика тяжела вне зависимости от языка программирования.

С языком все нормально - мы именно таким его и проектировали. Конечно же будем его и дальше улучшать, но серьезных концептуальных изменений сути языка не будет.

 
Renat:

В общем, обобщенный призыв "сделайте программирование простым". Но такого не бывает.

Работа разработчика тяжела вне зависимости от языка программирования.

С языком все нормально - мы именно таким его и проектировали. Конечно же будем его и дальше улучшать, но серьезных концептуальных изменений сути языка не будет.

Выскажу своё мнение. Сегодняшнее положение с MQL5 похоже как когда-то с турбопаскалем, т.е. он стал объектно-ориентированным, но ужасно неудобным. И только после выхода Дельфи всё встало на свои места. Это я к тому, что не хватает визуальной среды разработки. Другими словами, дайте возможность пользователям "рисовать" индикаторы и советники. Пойдите дальше в своём развитии и это многие оценят.

 
Renat:

Работа разработчика тяжела вне зависимости от языка программирования.

С языком все нормально - мы именно таким его и проектировали.

Нифига подобного. Это - заблуждение, от которого вы отталкиваетесь и потому допускаете ошибки, начиная с этапа самого проектирования.

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

 

Я думаю стоить разделить на 2 части суть поднятой темы

1. Это неудобство языка

2. Неудобство библиотек

Неудобство языка

Вы сами написали, что


Renat писал(а)  :

когда MQL5 по сути является "Managed C with Classes". Это не С++. В языке нет никаких сложных конструкций: ни эксепшенов, ни шаблонов, ни перегрузки операторов, ни прямых ссылок.

Он настолько прост, что просто ущербен, Скажем так он ни даёт никаких преимуществ для того для чего он создан - а именно создавать МТС. Нет ни одного элемента языка который облегчил эту задачу. Это всё те же for, while, ++, -- и т.д. Это обычный простой язык программирования. Единственное, что вы сделали выдающееся с этим языком это то что он стал управляемым, что позволяет вам утверждать, что вирусы на этом языке написать нельзя (кажется я правильно понимаю цель?). НО это не достоинство языка, это достоинство среды выполнения вашего языка. Пусть он будет производительным, но это опять не достоинство языка а среды выполнения.

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

Незнаю баг, это или так задумано, но думаю это всё-таки от отсутствия исключений, но от StringToDouble нельзя накаким образом добиться информации о том, что на вход подали ошибочное число. Получается, что если на вход подали фигню, то на выходе стойкий 0. При этом GetLastError сохраняет молчание. Такое поведение по меньшей мере преступно. В обычных языках это исключительная ситуация с генерированием исключения. Допустим GetLastError всё-же должен вернуть ошибку в этой функции. Как я должен реагировать на это? Видимо следующим образом

ResetLastError();
double v = StringToDouble(str);
if (GetLastError() != 0) {
   Print("Error");
   return;
}

А если таких мест десятки или сотни? Где тут забота о программисте?

Некоторые языки позволяют работать непосредственно с данными. Например Foxpro позволяет встраивать в код SQL запросы. C# c LINQ позволяет делать тоже самое, но с использованием ООП. Почему вам не подумать в этом направлении. Например подумать о конструкциях, которые облегчат работу с ордерами.

Ну про уборку созданных объёктов самим программистом, я вообще молчу. Не сделали сборщик мусора, ну и бог с ним, есть программисты, всего-то добавить пару строк кода - переживут, ну поломают голову, когда надо удалять объёкты, а когда нет. а мы им ещё несколько свойств, методов и поведений добавим.

А в результате малу помалу и код растёт и распухает как на дрожжях. 


Неудобство библиотек

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


Подводя резюме вышесказанному, можно сказать. Написать МТС на MQL - можно, но существенно сложнее чем на любом другом современном языке и не обязательно C#.

Вообщем - "Ёжики плакали, кололись, но продолжали есть кактусы"




 
cpp.forex:

Незнаю баг, это или так задумано, но думаю это всё-таки от отсутствия исключений, но от StringToDouble нельзя накаким образом добиться информации о том, что на вход подали ошибочное число. Получается, что если на вход подали фигню, то на выходе стойкий 0. При этом GetLastError сохраняет молчание. Такое поведение по меньшей мере преступно. В обычных языках это исключительная ситуация с генерированием исключения. Допустим GetLastError всё-же должен вернуть ошибку в этой функции. Как я должен реагировать на это? Видимо следующим образом

А если таких мест десятки или сотни? Где тут забота о программисте? 

На самом деле есть более существенный случай, когда отсутствие исключений уродует язык, а именно - когда ошибка возникает в конструкторе. Потому что конструктор вызывается неявно.

void OnStart()
{
  C a;

  /* Как здесь теперь узнать, что объект a использовать нельзя, потому что он не сконструирован ? */
  ...
}

Более того, классы могут быть сложными, с наследованием и подобъектами, то есть, одна строчечка, состоящая из 4-х символов ("C a;"), может породить вызов множества конструкторов, в наихудшем случае каждый из которых не сможет завершить инициализацию своего подобъекта...

Недоконструированный (недоинициализированный) объект использовать нельзя, это может привести к непредсказуемым последствиям, причём, необязательно сразу же. Более того, такой объект даже удалять нельзя, поскольку деструктор не знает, что объект недоконструирован! А в коде выше  деструктор незбежно будет вызван при выходе автоматической переменной "a" из области видимости.

Для устранения описанного уродства было предложено два варианта. Вариант добавить исключения был отвергнут. Вариант убрать конструкторы/деструкторы - тоже был отвергнут.

Конструкторы в MQL5 не могут принимать параметров, что делает их достаточно бесполезными. Вариант добавить параметры в конструкторы сначала был оставлен на обдумывание, но, в результате, тоже отвергнут.

 
cpp.forex:

Незнаю баг, это или так задумано, но думаю это всё-таки от отсутствия исключений, но от StringToDouble нельзя накаким образом добиться информации о том, что на вход подали ошибочное число. Получается, что если на вход подали фигню, то на выходе стойкий 0. При этом GetLastError сохраняет молчание.

Приведите пример, пожалуйста, как Вы подали на вход функции StringToDouble  неправильное число и что получилось в итоге. Просто хочется увидеть в чем состоит претензия.
 
Rosh:
Приведите пример, пожалуйста, как Вы подали на вход функции StringToDouble  неправильное число и что получилось в итоге. Просто хочется увидеть в чем состоит претензия.

Ну к примеру вот такой прикол (ошибка в знаке):

StringToDouble("2.25") - вернет 2.25, как и положено, а вот StringToDouble("2,25") вернет нам только 2...


А про неудобство работы с TimeToString(), я вообще молчу. Я конечно понимаю, что такой вид отображения дата и времени является стандартом для MT, но почему бы к примеру не добавить дополнительный параметра позволяющий отображать дату в более привычном глазу (возможно и другому ПО) формате ДД.ММ.ГГГГ....

PS

И на последок - А с каких это соображений TimeToString() секунды решил не показывать, ведь даже print() корректно дату отображает (а тут на тебе)...

 
Interesting:
И на последок - А с каких это соображений TimeToString() секунды решил не показывать, ведь даже print() корректно дату отображает (а тут на тебе)...

Задайте режим вывода TIME_SECONDS и Вы получите секунды. Об этом явно в документации сказано. Просто по умолчанию режим вывода TIME_DATE | TIME_MINUTES
123456
Новый комментарий
Причина обращения: