История MQL4?
Посему вопрос, есть ли перспективы по предоставлению API наружу?
Нет.
В 2002 году был выпущен новый информационно-торговый комплекс MetaTrader 3 (мы назвали его третьей версией, так как первой своей работой посчитали систему FX Charts, второй версией - MetaQuotes). В нем мы полностью переписали встроенный язык, назвав его MQL2 (странная ситуация получилась тогда - язык второй версии, а терминал - третьей).
Язык переписали из-за того, что первый MQL нам (и трейдерам) не понравился и его не имело смысла дальше развивать. Мы решили сделать язык MQL2 как можно проще, взяв за основу Easy Language от компании Omega Research (терминал TradeStation). Это была наша серьезная ошибка. На своем опыте выяснили, что делать язык "для непрофессионалов" - это утопия.
Непрофессиональный программист практически ничего хорошего на "простом" языке написать не может, а профессионал не захочет разучивать "недоязык". В результате решили еще раз с нуля написать язык заново, взяв за основу чистый язык Си.
Объявили о начале работ над новой системой осенью 2003 года. Как и раньше, с нуля переписали всю информационно-торговую платформу, назвав ее MetaTrader 4. Заодно и язык назвали MQL4.
MQL4 - это оптимизируемый и компилируемый в байт код язык. Очень быстрый. На проводимых ранее тестах были показаны следующие результаты:
На текущий момент с нуля разрабатывается новая версия MQL5, полностью совместимая сверху вниз с MQL4. В MQL5 есть классы, структуры и очень хороший оптимизатор.
Но одного я не пойму, если в третьей редакции (а сейчас близится четвёртая) используется синтаксис Си и происходит всё большее схождение к оному, то почему не взяли за основу существующие компиляторы (Watcom/GCC, как опция - использование msvc & icc) вместо написания с нуля? Слишком тяжёлые, чтобы с собой таскать? Оформить как SDK? Всё-таки MQL4 быстрый, но разница на порядок (что в некоторых случаях и не критично, но на тестах стратегий сказывается).
Невозможность предоставления наружнего API остаётся покрыта тайной :)
Надеюсь по крайней мере, что в месте с класами все встанет на свои места, и вместо использования в таком виде:
string s = Symbol();
int d = MarketInfo( s, MODE_DIGITS );
int s = MarketInfo( s, MODE_SPREAD );
Можно будет увидеть нечто в этом роде:
Market m = Symbol.Current.Market;
int d = m.Digits;
int s = m.Spread;
Или еще проще:
Market m = Market.Current;
int d = m.Digits;
int s = m.Spread;
По крайней мере это уже будет намного проще и более понятная, именно объектная модель, а не набор функций, так как все взаимосвязано, именно это отличает примитив от простоты и его легкого освоения. Причины реализации языка могут быть разные, я даже не берусь осуждать или поощерять это событие, но я могу сказать наверняка, что выбор зависит от действительной простоты и удобства использования.
Например когда люди осваивают .NET они делают главную ошибку, они стремятся получить простоту из привычного примитива API, с одной стороны это легко понять, с другой стороны, начинаются другие проблеммы, при написании многофункциональной машины, объемы кода. Когда я писал на VB именно так и было, хотя там есть классы, поэтому C++ был куда удобнее хотя тогда, это было еще более непонятно, до сих пор не понимаю зачем усложнять жизнь, подразделяя код на содержание и описание. .NET решил для меня все эти проблеммы, когда я на него переходил, это было пределом мечтаний, но до сих пор мешают старые методики, которые были выработынаны использованием приведущих языков, хотя я тогда тоже пытался писать на Java но это было так убого, в связи с этим бидламом я ушел в скриптинг, тогдашний Perl, JavaScript, VBScript показал мне в полной красе всю беспомощность моего положения и появление .NET вернуло меня в свою стихию, плюс позволило разойтись в любом нужном направлении, правда это было с таким трудом, что приходилось доказывать исключительность концепции .NET самому себе, чтобы не бросить его, хотя это и позволяло отвлекаться в самых разных направлениях. .NET был самым сложным этапом стыковки в моей жизни, хотя и наиболее удачным в освоении. Я чувствую и понимаю его наверное в той степени в которой нужно. Наверное как и все программеры я пытался разработать что-то более, но в итоге чего-то более оказалось пропастью и потерей времени, глупость заключается в том, что что-то более не охарактеризовано на уровне более:) Поэтому упростить сложное куда нужнее, чем усложнить простое, но простота обманчива:)
Но речь не об этом, речь о том, что успешность языка как раз и определяется многими такими факторами. Я вижу что MQL достиг того, что необходимо, он достаточно удобен и прост, но в рамках примитива, как только эти рамки будут сняты, возможно многое изменится.
З.Ы.: Не спрашивайте меня зачем я об это написал, я не продвигаю какую-то технологию, я размышляю об удобстве на основании того что я знаю.
Больше чем уверен, что пользователи сами сделают всю работу по преобразованию и появятся такие классы как, если не будет свойств, будут методы, что вобщем-то одно и тоже, за исключением написания двух методов для реализации простого свойства, а те кто не захочет упрощать свою жизнь за счет увеличения запросов, будут так же придерживаться своих методов, делая множество многократно повторяемого кода и т.д. Пример проще чем реальность того что из этого сделают, если включить проверку исключений, то классы будут всепоглощающими, вобщем по стопам .NET пойти не сложно, даже без полноценной характеризации типов, что говорить если я в C++ встраивал идеологию .NET, правда она была настолько большая, что проще было не парится и использовать .NET потому что получалось практически одно и тоже, а кода написано было в разы больше, да и что коворить о том что надо плодить заголовки и другие файлы чтобы потом это еще и использовать в других программах, плодовитость C++ ужасает, но лучше и правельнее ничего нет, потому что совершенство нам только снится, в итоге например драйвер превращается в головную боль, не говоря обо всем остальном. Когда встаешь между MASM и С++ встают точно такие же делемы... Вывод, миром правит простота, точнее желаниями людей.
class Market {
string mSymbol;
Market( string iSymbol ) {
mSymbol = iSymbol;
}
static int Current {
get return new Market( Symbol() );
}
int Digits {
get return MarketInfo( mSymbol, MODE_DIGITS );
}
}
Я вот до сих пор не понимаю зачем в MQL нужны скобки для оператора возврата, лишние символы без которых можно обойтись, все понимаю но это выше моих сил... Это тоже самое что for или if в обязаловке принудить к символам блока кода, для одного выражения.
Это почти как сравнение Java и того же VB.NET с тем же C# в каждом всегда находится масса мелочей которые играют против языка, в .NET стало проще, выбор гарантируется на основе языков, самый чисты и лишенный всякого борохла оказался C#, до мелочей все продумано и версии языка с каждым приращением все краше и краше. Чего не скажешь о VB и MC++. Я уже молчу про J#, который воплощает бардак понятий. О Python, Ruby думать даже не приходится, C всегда был и остается самым красивым и удобным, а C с четыремя плюсами или вернее с решеткой само совершенство из вариаций языков C.
З.Ы.: Мне глубоко фиолетово кто внимает моим словам и кто нет, но в своих же интересах, которые не многим отличаются от большинства страждущих, я пытаюсь хоть что-то объяснить на пальцах, тем от кого все то самое удобство зависит, я нашел свое удобство, я использую .NET в необходимом смысле, мне хватает, извращаюсь, парюсь иногда с непривычки, но использую успешно, на большее как правило даже не надеюсь, наверное только так кажется:) Пока я пишу об этом, меня посещают мысли о другом, расслабляюсь, таким образом, так что можно не принимать как какое либо наставление:)
Я вот до сих пор не понимаю зачем в MQL нужны скобки для оператора возврата, лишние символы без которых можно обойтись, все понимаю но это выше моих сил... Это тоже самое что for или if в обязаловке принудить к символам блока кода, для одного выражения.
Может, return является функцией a-la stop-it-now :) а не частью синтаксиса.
З.Ы.: Мне глубоко фиолетово кто внимает моим словам и кто нет, но в своих же интересах, которые не многим отличаются от большинства страждущих, я пытаюсь хоть что-то объяснить на пальцах, тем от кого все то самое удобство зависит, я нашел свое удобство, я использую .NET в необходимом смысле, мне хватает, извращаюсь, парюсь иногда с непривычки, но использую успешно, на большее как правило даже не надеюсь, наверное только так кажется:) Пока я пишу об этом, меня посещают мысли о другом, расслабляюсь, таким образом, так что можно не принимать как какое либо наставление:)
Можно нескромный вопрос? Неужели вы думаете что способ программирования стратегии может каким-то образом сказаться на её результативности? Иначе к чему такая активнейшая агитация с вашей стороны за . NET во всех ветках форума? Те люди, которым .NET действительно нужна, разумеется уже давно на неё перешли, но подавляющее большинство экспертописателей скорее всего решают все вопросы по стратегиями обычно с помощью возможностей MQL4. Я уже 2 года программирую на MQL4 и пока что не могу представить себе задачу (стратегию), которую невозможно было бы реализовать в самом MQL4. Хотя возможно что существуют какие-то монстрячные системы, которые требуют более быстрых вычислений во внешних dll. Хотя опять-таки результативность таких внешних вычислений (эффективность для торговли) нигде не приводится.
Я допустим не владею .NET на вашем уровне, но пока что не нашёл ни одного убедительного довода в пользу того чтобы взять и изучить её специально ради написания экспертов для МТ4. Основные доводы, которые вы приводите, заключаются в том что .NET "гораздо удобнее", чем MQL4. Могу сказать вам что это исключительно субъективное мнение человека, который в совершенстве владеет .NET! Мне вот в текущий момент времени "гораздо удобным" кажется MQL4, поскольку я на нём легко могу реализовать всё что мне может прийти в голову, так как имеются отлаженные готовые функции, из которых очень быстро собираются разные советники с разнообразными алгоритмами работы. А вот для реализации того же самого на .NET мне нужно будет ещё его полгода поизучать. И ради чего спрашивается???
Именно этот вопрос и останавливает использование других языков.
Сейчас и из dll написанной на VC++ нельзя получить бесшовный доступ к данным вызвав из длл функцию например типа getBars, getNumberOfOrders, orderSend createObject и так далее.
Приходится передавать данные в DLL из советника и забирать в советнике для отображения на чарте или чтобы окрыть или закрыть ордеры. Так же приходиться иметь внутренний массив позиций.
Воoбщем этот "шов" между MQL4 советником и DLL где у меня вся логика стратегии замедляет работу и приходится много функций прописывать для передачи параметров. Можно конечно зарезервировать массив double и в советнике приводить к нужному типу, но лучше было бы оперировать структурами и совершать действия в терминале вызывая нейтивные интерфейсные синхронизированный функции терминала. Так же набор прототипов функций которые будут вызываться из пользовательской DLL на какие-нибудь события - например на клик мышкой на чарте и так далее. Лично мне бы очень хотелось таких возможностей в MT. Можно задействовать COM в этом случае не будет ограничией какой MS язык используешь. С явой думаю будет посложнее но есть альтернатива типа .NET
MQL4 для тех кто других языков не знает или кому его простота и скорости выполнения достаточны. Для тех кто хочет оптимизировать своими средтсвами или критична сильно скорость исполнения стратегии будут разрабатывать на C++ или Delphi.
Похоже, что немногие задумываются над вопросом "Как объединить чужой язык со своей моделью данных?". Как быстро и бесшовно получать прямой доступ из того же .NET/Java кода к мельчайшим настройкам/данным терминала?
Именно этот вопрос и останавливает использование других языков.
Ренат, не уж то вы об этом все же промолвили слово?! Я не верю своим глазам:) Да вы абсолютно правельно заметили! Это волнует основное большинство, хотя каждый находит для себя выход сам, я например для этого использовал многообразие возможностей, например двойные вызовы, но не прямой доступ к памяти, так как все мы хорошо понимаем, что это очень трудоемкое занятие и практически бессмысленно:) Думаю тех кто на это способен это врядли останавливает, но неудобств действительно масса:) А вот в цикле обработать обратные запросы кое как получается и даже можно обработать какие-то события:)
Говоря об основном большинстве, я говорил о тех кто видит большие возможности, а не только возможность просто программировать и получать малый результат в силу своих потребностей и возможностей. Если задать вопрос именно так как вы задали, то наверное нас меньшинство, потому как вряди кто-то пишет для этого целые комплексы, восновном люди предпочитают привинчивать к этому уже кем-то созданные комплексы. А если воспользоваться поиском то вопрос о .NET и других языках вставал с такой переодичностью, что можно собрать целую энциклопедию, прежде всего поэтому я не думаю что это волнует только меня:) А сколько разработчиков ни слова не говоря просто проходят мимо:)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
А вопрос в следующем. С чем связано написание собственного языка/компилятора вместо предоставления единственного API с возможностью написания биндингов под всё, что компилируется/исполняется? C/C++, Java, C#, Python, Ruby...
Из особенностей (я новичок в MQL4), присущих MQL4 могу выделить:
- Нечто вроде байт-кода/CLR
- который при этом шифруется в EX4
- и отсутствие коллбэков как следствие, видимо, из п.1
- Отсутствие оптимизации при компиляции. На примере обработки
условий в конструкциях if, где в документации явно прописано, что выполняются все выражения
независимо от результата предыдущих выражений. Видимо, в существующих
масштабах это не критично.
- Отдельное разрешение на вызов библиотечных функций. У меня в
голову приходит только один вариант -- чтобы народ ничего лишнего
снаружи не мог вызвать/удалить/поломать, если скрипт/индикатор/эксперт
запускается, например, на чужой машине.
Я не сильно знаком с историей MQL, но подозреваю, что первая/вторая версия дала ощутимый толчок к поголовному написанию всевозможных индикаторов, скриптов и т.д, откуда и пошли эксперты (если они сразу не появились). А дальше снежный ком всё нарастал, как это было с тем же PHP, который изначально был неким шаблонным языком при работе с html (лет эдак 10 назад) с минимум возможностей.Посему вопрос, есть ли перспективы по предоставлению API наружу?