О MQL4 - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ява по синтаксису очень мало отличается от С (поскольку от него происходит, как и MQL), но имеет совершенно другое внутреннее устройство, о чем пользователь зачастую просто не догадывается. Более того, транслятор MQL производит на свет некий байт-код, а не настоящий двоичный, и тем самым сходство с Явой еще усиливается (*.mq4 --> *.ex4, равно, как и *.java --> *.class -- это байт-код). Если попробовать написать на Яве что-то мало-мальски серьезное, взвоешь гораздо раньше и сильнее, чем от MQL, несмотря на все его заморочки. Попробуй -- сам убедишься.
Кстати, почти тоже самое можно сказать и про Бейсик.
Так почему именно С, а не эти языки?
Кстати, почти тоже самое можно сказать и про Бейсик.
Так почему именно С, а не эти языки?
Думаю, по соображениям упрощения процедуры написания и отладки транслятора с MQL, а также для придания ему сравнительно недорогой ценой свойств некоторой расширяемости. Впрочем, это внутреннее дело MQ. Насчет Паскаля и других языков еще раз повторю свое частное мнение: в принципе все равно, что брать за основу процедурного языка программирования, хоть бы и Рапиру (было такое древнее русскоязычное бейсикоподобное порождение отечественной программерской мысли). Единого стандарта для языков программирования торговых стратегий, насколько я понимаю, пока еще не разработано, поэтому каждый разработчик волен поступать так, как ему заблагорассудится. В данном случае разработчики исходят из соображений упрощения себе жизни, в чем я их безоговорочно поддерживаю и одобряю.
Позволю себе здесь не согласиться. Одни языки более предрасположены к ошибкам, а другие менее. С относится как раз к первой категории.
Мне всегда казалось, что разработчик должен писать программу так, чтобы упростить жизнь пользователю, а не себе. Неужели я сильно заблуждаюсь?
Главное, чтобы не было ляпов в трансляторе и язык был хорошо документирован. Это главная задача разработчика. Насколько я понял, документация по МТ-МЕ сейчас радикально перерабатывается. К транслятору в общем-то тоже претензий практически нет. А научиться писать программы без ошибок -- это уж задача юзера.
Если он пишет свой софт только как коммерческий, т.е. речь не идет даже о shareware. В Интернете можно найти массу примеров торговых платформ и коммерческих аналитических программ стоимостью 1К долл. и выше. МТ -- полностью freeware клиентский терминал, выложенный в открытом доступе для бета-тестирования. Поэтому слово разработчика в данном случае является решающим. Сюда же теснейшим образом примыкает и вопрос о клиентском API, а именно, о лицензировании его freeware-использования. Это мне объяснял специалист по авторскому праву, когда возникла такая надобность. Правда, большей части объяснений я так и не понял.
С точки зрения юзера выбор предлагаемого ему производителем языка должен быть ему безразличен.
Что Паскаль, что С, что Ява, что Бейсик, что Рапир, Алмир, ПЛ или Фортран. Потому, что по сути дела внутренний механизм этих языков всё равно полностью скрыт от пользователя. Что, в сущности, пользователь "чувствует", как язык? Знак равенства обозначается по-разному, да точка с запятой где-то ставится, а где-то нет. Ну, ещё пара мелочей. И всё. И в любом языке важно соблюдать общие закономерности построения кода: чтоб циклы не пересекались, переменные вовремя обнулялись, не допускать зацикливания и пр.
Иное дело, что конкретно в MQL есть ф-ии, кот. нет и быть не может в "неторговых" языках. И с ними всё равно необходимо знакомиться независимо от языковой основы.
А учитывая скоростные характеристики, реально достигнутые разработчиками MТ4, мы получаем к рассуждению серьёзный аргумент в пользу их правильного выбора.
Что такое скорость для языка программирования?
Это бОльшее количество операций за единицу времени.
Что это дает трейдеру?
Возможность реализовать сложнейшую логику в реальном режиме времени.
Более изощеренные индикаторы, более сложные логические условия и меньшее количество времени в тестировании стратегий.
Скорость - это то, ради чего можно пожертвовать мнимой простотой "других" языков.
"MQL4, MQL2, EasyLanguage, Wealth-Lab 3.0 и VC++: сравнение скорости"
Качество (это не только количество ошибок, но и производительность и потребляемые ресурсы) программирования зависит от программиста.
И совсем слабо от языка. Кто-то использует "помехоустойчивый" язык и создает такое тормознутое решение, что им пользоваться невозможно (зато меньше ошибок на 1000 строк кода!). А кто-то ошибается, исправляет, но пишет исключительно быстрый и защищенный код.
На этом предлагаю завершить эту тему.
Иначе скоро будет черта, за которой - очередная священная война за лучший язык программирования.
Подписываюсь под этими словами. Именно это и дало возможность проверить некоторые достаточно изысканные идеи в реал-тайм режиме, не тратя время на разработку и программирование собственного софта и на импорт\экспорт котировок. Подозреваю, правда, некоторые странности в работе встроенных функций обработки массивов, но это отдельная тема. Пока что отказался от использования функции ArrayCopy() (на нее падает главное подозрение) в кастом-индикаторе, который вызывается экспертом при тестировании (на демо все работает нормально), однако еще не уверен, что это не мои заморочки, а баги в МТ. А "дискуссию о языкознании", пожалуй, действительно пора завершить.