хотелки
Есть ряд разработок на тему графического MQL кодинга, например EA Tree с блочным драгндропом. Я тоже считаю что за узловыми системами будущее, но есть много НО, такая система должна быть гибридная, то есть обязательно должна быть возможность редактирования кода каждого узла\блока и создание кастомных узлов в текстовом режиме. Иначе это игрушка для малышей. Большинство высокоуровневых САПРов так работают, это в сотни раз ускоряет разработку шаблонных архетектур, и на тонкую кастомизацию по готовому скелету остаётся гораздо больше времени. Безусловно за такими решениями будущее.
Есть ряд разработок на тему графического MQL кодинга, например EA Tree с блочным драгндропом. Я тоже считаю что за узловыми системами будущее, но есть много НО, такая система должна быть гибридная, то есть обязательно должна быть возможность редактирования кода каждого узла\блока и создание кастомных узлов в текстовом режиме. Иначе это игрушка для малышей. Большинство высокоуровневых САПРов так работают, это в сотни раз ускоряет разработку шаблонных архетектур, и на тонкую кастомизацию по готовому скелету остаётся гораздо больше времени. Безусловно за такими решениями будущее.
Чем плох на эту роль стандартный мастер стратегий в MQL5? Там тоже можно описать соответствующий модуль сопровождения позиции и использовать его в качестве кирпичика эксперта:
Чем плох на эту роль стандартный мастер стратегий в MQL5? Там тоже можно описать соответствующий модуль сопровождения позиции и использовать его в качестве кирпичика эксперта:
Стандартный хорош. Но есть куда расти.
Узловые редакторы давно применяются в производстве цифровой графики высокой сложности, это позволило в последнее десятилетие сделать прорыв в качестве и скорости.
Когда-то вообще считалось что и компьютеры это только для ученых)))
Должен быть баланс в скорости, простоте использования с одной стороны и кастомных возможностях с другой.
99% ТС это шаблоны. В узловой оболочке типа EA Tree классическая ТС на МАшках с примитивным ММ, «рисуются» за пару минут. С какой такой стати трейдер должен тратить больше времени или недай бог заказывать такой примитив? Но это вторично. Главное это то что графическое представление куда больше похоже по структуре на исходный алгоритм, чем тысячи строчек кода, понятна структура и соответственно быстрей идёт творческий процесс перебора вариантов, тестирования, поиска идей и тп.
Любое не шаблонную функцию можно дописать и воткнуть в дерево, как отдельный узел. Короче эта практика давно проверена с фантастическими результатами. Препятствия чисто психологические у хардкор-кодеров, которые чувствуют угрозу конкуренции людей более творческих, которые по статистике менее мотивированны к рутинной внимательной деятельности, бесконечным отладкам и тп.
Стандартный хорош. Но есть куда расти.
Узловые редакторы давно применяются в производстве цифровой графики высокой сложности, это позволило в последнее десятилетие сделать прорыв в качестве и скорости.
Когда-то вообще считалось что и компьютеры это только для ученых)))
Должен быть баланс в скорости, простоте использования с одной стороны и кастомных возможностях с другой.
99% ТС это шаблоны. В узловой оболочке типа EA Tree классическая
ТС на МАшках с примитивным ММ, «рисуются» за пару минут. С какой такой стати трейдер
должен тратить больше времени или недай бог заказывать такой примитив? Но это вторично. Главное это
то что графическое представление куда больше похоже по структуре на исходный алгоритм,
чем тысячи строчек кода, понятна структура и соответственно быстрей идёт
творческий процесс перебора вариантов, тестирования, поиска идей и тп.
Любое не шаблонную функцию можно дописать и воткнуть в дерево, как отдельный узел. Короче эта практика давно проверена с фантастическими результатами. Препятствия чисто психологические у хардкор-кодеров, которые чувствуют угрозу конкуренции людей более творческих, которые по статистике менее мотивированны к рутинной внимательной деятельности, бесконечным отладкам и тп.
Не забывайте, что в хорошей торговой системе большая часть кода может быть проверкой ошибок и восстановлением после сбоев. И даже "засунуть всю обработку всех ошибок в шаблоны" не очень понятно как реализовать.
Звезда RAD средств закатилась много лет назад, к сожалению. Оказалось, что "таскать формочки" - это не массово, очень ограничено и никак не удовлетворяет потребителей.
Не забывайте, что в хорошей торговой системе большая часть кода может быть проверкой ошибок и восстановлением после сбоев. И даже "засунуть всю обработку всех ошибок в шаблоны" не очень понятно как реализовать.
Звезда RAD средств закатилась много лет назад, к сожалению. Оказалось, что "таскать формочки" - это не массово, очень ограничено и никак не удовлетворяет потребителей.
Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.
Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.
На текущий момент продукты так и создаются большей частью в рукопашную. Да, компоненты и библиотеки сильно помогаю, но все остальное - только ручками.
Многие компании-разработчики рад систем на практике осознают результаты, а потом тихо сливают продукты.
Если говорить о замене программирования, то тут рады почти не помогают. Например, они понятия не имеют и не могут предложить способа экономного пересчета индикаторов. Без знания практик программирования никак. кроме того, обычно рады дают такой дикий оверхед по производительности, что результаты слабо применимы в тяжелых рассчетах.
- 2010.06.29
- Nikolay Kositsin
- www.mql5.com
Я тоже думал, что такая штука будет удобной. С возможностью просто вставлять свои блоки/код и также легко творить.
наверно тут легче выучить язык, чем учить другую программу, Тем более MQ дает гибкие библиотеки, делай что хошь называется.
Идея с созданием такой системы и у меня была, но тут скорее всего сработал принцип СПРОС - ПРЕДЛОЖЕНИЕ, мало спроса, программа не будет иметь большую популярность.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
День добрый всем присутствующим!
В связи с тем, что MQ5 по сравнению с 4кой стал на две головы выше, может быть пришло время подумать о визуальном MQ? Я к тому, что формы, поля для редактирования и прочее (в конце концов и шаблон эксперта, видимо) проще было бы добавлять из стандартных средств вроде того, как это сделано в других Visual языках (цепляем мышкой иконку эксперта и тащим на формочку). Но это как бы на удаленное будущее, а в рамках недель было бы неплохо иметь хотя бы _специальное окно_ для всевозможного вида управляющих панелей, таблиц. Сейчас приходится для этого создавать какой-нибудь "левый" график, затаскивать его в угол (например, ставить фиксированный масштаб 0.001 - 0.0001, убирать сетку, убирать OHLC и прочее ненужности). Минусом такого окна является то, что приходится отлавливать в циклах работающих со всеми окнами конкретно это и ставить доп.условие на пропуск окна. В общем хотелось бы услышать комментарии разработчиков, людей в теме. Ждать нам в ближайший год, например, Visual MQ или хотя бы некий отдельный полигон для отработки мультивалютных панелей, таблиц с методом onAnyTick() ;)
Спасибо!!!