продолжение статьи про выбор языка

выбор языка, часть 2

Собираю из тетрадок, закладок и памяти те материалы которые повлияли на выбор Tcl для интеграции с MQL Текста получилось неожиданно много и очевидно будет ещё и третья, заключительная часть А а этой - рассмотрение претендентов на компонент расширяющий возможности MQL

Взял смелость и в статье объединяю большие «числогрызы» в одну главу. Они не решат наших задач про «взаимодействие с миром», про GUI, и так далее, но они востребованя. На них, с их помощью, благодаря им делаются и отрабатываюся торговые стратегии.

Начну с R, так получилось что с практикой его применения в MT знаком очень плотно. Фактически это первый язык который было предложено интегрировать в MT. (привет и уважение г-ну Фоменко , как главному «двигателю» того действия)

R (https://www.r-project.org/) это хорошая, но большая система. исторически это «очень-очень» толстая Scheme ( в подростковом возрасте S-, а потом R- Lang, но быстро переименовались). Если посмотреть изнутри, то там классические для потомков лисп s-expr, но весьма разбухшие. Даже не вдаваясь про тред-модель интерпретации, честно сказал - «это очень дорого стоит и займёт кучу времени». Любопытствующие могут глянуть http://developer.r-project.org/embedded.html и https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Handling-R-objects-in-C

На мой взгляд, если взять R и впрямую пытаться его интегрировать, то это просто погрязнуть разбираясь в его SEXP. С ним нужно общаться через консоль - делать из данных текст перед отправкой и получать обратно текст преобразуя в данные. И надеюсь Mt-4R на сохранении которого настоял, всех устраивает.

С популярной системой символьных вычислений Maxima http://maxima.sourceforge.net/ та-же самая ситуация, разве что maxima - внутри это чистая scheme (помните, выше было про Guile?). С ней тем паче проще общаться через консоль :-) В символьные системы мы отправляем запись формул и обратно тоже получаем запись формул (упрощенную/преобразованную и проч). Возможность считать данные - это побочный эффект.

Два близких аналога MatLAB: Gnu/Octave https://www.gnu.org/software/octave/ и SciLAB http://www.scilab.org/ и язык «написанный математиками для математиков» Julia https://julialang.org/ позволяют разрабатывать рассчётные/аналитические программы и вообще разбираться с данным. Если вам надо проводить громадные вычисления или задействовать облака/гриды/суперкомьютеры то имеет смысл их задействовать (в sci-lab и julia это доступно «из-коробки»). Но такие вычисления проводятся не за секунды, а всё что надо посчитать между тиками вполне успевает рассчитывать MQL.

Стоит ещё упомянуть PSPP https://www.gnu.org/software/pspp/ программа для стат.анализа, отдельные полезные библиотеки например https://www.gnu.org/software/gsl/ или https://www.coin-or.org и прочее. Можно вообще писать отдельную статью - коллекцию ссылок полезного в анализе софта. Его очень много.

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

если вы всё-же вознамеритесь писать свой язык/интерпретатор на MQL, то у вас гарантированно будет получаться одно из 3-х: форт, лисп или паскаль :-) Построение и «раскрутка» Форт и Лисп детальнейшим образом дана во всей классической ИТ литературе. Не поленитесь - полазьте по интернету. Паскаль тоже даже более широко известен, поэтому по нему будут попадаться масса блогов и удачных/неудачных реализаций (интерпретатор паскаль - это типовая студенческая курсовая работа). Поэтому про паскаль читайте Вирта и разбирайтесь с p-code.

Сказав про паскаль нельзя не сказать про промежуточные коды и виртуальные машины. Вполне рабочим решением «интерпретатора на MQL» может быть портирование какой-либо виртуальной машины. Несмотря на «страшное слово» это может быть значительно проще чем написать интерпретатор языка. Есть разные виртуальные машины и переносимые коды. Это вовсе не обязательно громадьё clr (common language runtime майкрософтовский .Net) или jvm (java virtual machine). Паскаль когда-то так и распространнялся - была простая спецификация пи-машины, которая умела исполнять p-code (портабельный код, типа высокоуровнего асемблера). Машина просто реализовывалась на новой архитектуре, и на неё ставился паскаль написанный в этих-же кодах.

В качестве готового языка с пи-кодами посмотрите Pawn https://www.compuphase.com/pawn/pawn.htm . Его машину точно можно очень компактно написать на MQL, а поддержка таймеров, конечных автоматов и состояний очень даже к месту при программировании роботов. Да и визуальный редактор «сложи программу из кубиков» имеется

Ещё немного материалов и ссылок про интерпретаторы:

  • Pico-C https://github.com/zsaleeba/picoc подмножество С, работает с ограниченным числом типов, зато интерпретатор очень небольшой и с ним легко разобраться и адаптировать под свои нужды
  • Pike http://pike.lysator.liu.se/ - тоже С-подобный язык. Но уже «продвинутый». Нелишне посмотреть, чтобы знать что примерно вас ждёт (какой объём работы) если начнёте писать свой язык/интерпретатор :-)

Решение написать свой язык/интерпретатор на MQL хотя и трудоёмко и рисковано, но может дать существенный бонус - программа будет работать на VDS MetaQuotes, её можно продавать через маркет или использовать при оптимизации в облаке. Вы можете например сделать советник, продать его через маркет и поставлять дополнения в виде скриптов.

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

Любой кто писал на MQL «транслятор арифметических формул» или «калькулятор со скобками» почти реализовал Forth или Lisp. в зависимости от применённого способа разбора выражений :-) Это просто классическая классика. Но оба языка коренным образом отличаются от MQL и их синтаксис смотрится как язык с другой планеты. Forth к тому-же считается низкоуровневым языком и применяется во всякой аппаратуре. Библиотек подходящих для трейдинга вы вряд-ли на нём найдёте.

В качестве Lisp-подобного (производного) языка можно рассмотреть Guile https://www.gnu.org/software/guile/ , это диалект Scheme (кстати R тоже произошёл от scheme, так сказать племянник Guile). Он спроектирован и предназначен для встраивания и расширения систем. Рекомендован проектом GNU и используется во многих продуктах. Большинство библиотек Scheme с ним работают и в плане прикладных библиотек и комьюнити всё хорошо. Останавливает только разительно отличная от MQL парадигма, это функциональный язык. Переключаясь от MQL к Guile придётся всё время «выворачивать» мозг. Поэтому пройду его мимо.

С и С++ подобные интерпретаторы, например Cling (https://root.cern.ch/cling) используемый при анализе данных CERN, не кажутся подходящими. Есть ещё проприетарный Сh (http://www.softintegration.com/products/), для общего развития стоит ознакомиться.

Использование скриптов подобных С++ внутри языка подобном С++ не сделает запись алгоритмов проще или их исполнение быстрее.

То-же относится и Паскалю и его производным. Не стоит делать скрипты такого-же уровня что и MQL - какой в этом толк ?

Про Паскаль вообще печально, он когда-то был просто эталоном интерпретации, а сейчас чистый интерпретатор не найти. Есть очень хорошие компиляторы, они строят хороший код, и использовать их в связке с MQL проще чем C++. У плюсов нет ABI и их классы надо «надо протягивать через игольное ушко». Но мы ищем язык для встраивания, а не на чём писать DLL :-)

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

Оф. сайт https://www.python.org/, а интересующая нас документация https://docs.python.org/3/c-api/index.html и https://docs.python.org/3/extending/index.html и совсем уж наше https://docs.python.org/3/extending/embedding.html

Отвлекаясь от темы - сайт и документация, прямо таки эталон как надо делать. По сравнению с питоном все прочие упомянутые сайты выглядят блёкло, а документация недостаточной. Молодцы, не зря они лидеры!

И сразу после похвальной речи - здоровенная ложка дёгтя. Интерпретатор питон может быть только один на процесс. Возможно и есть способ выйти за рамки официальных рекомендаций авторов и заставить работать несколько питонов, причём по несколько штук на нить, но не факт что это получится и вообще стоит за такое браться. Кроме того в питоне есть большой grand-lock, это когда нить управляемая интерпретатором захватывает общий для всех ресурс и препятсвует работе прочих.

Попытка полноценно встроить питон будет чревата тем, что например индикаторы его использующие начнут конфликтовать друг с другом - создавать/ удалять одноимённые переменные, подгружать модули и прочее. В принципе это может нивелироваться общими соглашениями про именования, порядок использования модулей/классов и подобными вещами. Но на уровне честного слова :-) Вы поверите что все авторы всех скриптов будут всегда чётко следовать правилам ? Я не верю в такие чудеса

Поэтому к сожалению питон отпадает. Очень жаль

Очень популярный объектный язык, с красивым синтаксисом. К тому-же стандартизованный ISO и признанный на уровне w3c.

Оф.сайт : https://www.ruby-lang.org , симпатичный сайт, что для основы RoR (Ruby-ob-rails) не удивительно. Обучение и пользовательская документация на высоком уровне. А вот документация для разработчиков сильно страдает. Неприятно поразили. Можете попробовать поискать embedding ruby - очень быстро выйдете на 3 странички оф.сайта взаимно ссылающихся друг-на-друга :-)

Не буду тянуть - с Ruby в точности такая-же проблема что и с Питоном. Контекст языка только один на процесс, и точно такие-же выводы что и с Питоном. Браться за проект по встраиванию Ruby в торговую платформу слишком рискованно.

В отличии от Питона, есть спастельный круг - авторы озаботились разработкой встраиваемой версией языка: mRuby http://mruby.org/

и вот в нём уже, с моей точки зрения, всё как надо - интерпретаторов может быть несколько, каждый работает независимо со своим контекстом. И довольно удобный API. И даже солидный пакет библиотек (Gems). Смущает только 2 вещи, но они серьёзны:

  • mRuby не соответствует стандарту ISO. На сайте скромно, по менеджерски «соответсвует части стандарта». Что на мой взгляд как рыба второй свежести.
  • и соответсвенно вызывает сомнение полная совместимость библиотек (гемов) mRuby и «большого» Ruby. И хотя заявленный список Gems уже «мечта программиста MT», но это капля в море по сравнению с Ruby

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

Не буду отвергать - mRuby выходит в финал, несмотря на трудности (а у кого их нет ?)

Правильнее конечно говорить о языке на базе ECMA Script, что примерно одно и тоже (JS - это ECMA с DOM-моделью, некоторым вводом/выводом и ещё некоторыми наворотами). Очень широко распространнённый язык, хорошо знакомый программистам, стандартизованный. Помимо википеидии, отправная точка для любознательных : https://developer.mozilla.org/en-US/docs/Web/JavaScript

Более-менее развитые и доступные нам «движки», не прибитые гвоздями к броузерам :

  • v8 от Google https://github.com/v8/v8/wiki реализует последнии вресии стандарта, считается самым быстрым, имеет встроенную JIT компиляцию. Отличная штука, но с жирнючим минусом - он не подходит для модели тредов MT. v8 дозволяет иметь только один интерпретатор на всё приложение.
  • v7 от Cesanta https://github.com/cesanta/v7 реализует более старую версию стандарта, зато минималистична. Очень компактная реализация и удобный API. Подходит для MetaTrader и более того, гарантированно в нём работает. Пробовал - замечательно получается. Можно строить библиотеку вокруг v7 и использовать JS для повышения гибкости программ MQL. Но с v7 другая засада - лицензии. Программы использующие cesanta v7 должны распространняться либо под GPL (с открытым кодом) либо требуется приобретение коммерческой лицензии. По лицензионным ограничениям мы не сможем использовать v7
  • ChaiScript http://chaiscript.com/ движок ECMA для С++. headers-only. Чтобы его «пропихнуть» через DLL и использовать с MQL надо будет весьма сильно извернуться. Очень много видится промежуточного кода, поэтому плотнее не смотрел, но в обзор включил. Если кому интересно - попробуйте.
  • QtScript http://doc.qt.io/Qt-5/qtscript-index.html - движок ECMA фреймворма Qt. Но чтобы его задействовать придётся «подружить» Qt и MT. То есть сначала заставить работать фрйемворк через DLL внутри MetaTrader. Задача конечно интересная, и если её решить можно потом «клепать расширения» в больших количествах и с высоким качеством. Но непонятно можно ли этого вообще достич, и объём работы видется очень большим. Чрезмерно большим

Сразу замечу что невзирая на гибкость, современность, распространённость JavaScript, специализированных мат.стат. библиотек практически нет. Даже вообще коллекций обще-целевых библиотек нет. Какой-бы движок JS/ECMA мы не выбрали, прикладных библиотек к нему не будет, их придётся делать самим или собирать с-миру-по-нитке.

Поэтому ECMA движки не берём, невзирая на то что Cesanta v7 работает в MetaTrader

Когда речь заходит о том чтобы «встроить скрипты» в программу, первое что приходит на ум - lua http://www.lua.org/ Язык изначально делался для встраивания в приложения, имеет очень простое C API и сам по себе не очень сложный. Довольно интересна табличная модель данных в интерпретаторе, и эта модель очень близка к потокам данных которыми оперируют трейдеры.

Собственно по этим двум причинам Lua уже активно используется в трейдинге и является основным языком популярных платформ QUICK и FXCM TradeStation. Интеграция Lua потенциально позволит делать «межплатформенные» программы или хотя-бы библиотеки. А если когда-нибудь удастся запустить не просто Lua, а LuaJIT (http://luajit.org/) - то вообще замечательно, это один из самых эффективных JIT компиляторов на текущее время, что делает lua очень-очень быстрым языком.

Есть конечно и нюансы - на моей практике авторы языка периодически «ломали» совместимость с прежними версиями. Мало того что из-за простоты языка каждая «большая» система вносит в него свои изменения, так ещё и база менялась. Как результат - сколько серьёзных приложений использующих Lua, столько вариаций языка и библиотек.

Будем надейтся что «болезни роста» lua закончились, процесс развития стал стабилен. Lua - естественный кандидат для достижения наших целей.

Классика встраиваемых языков и вокруг-научного софта http://tcl.tk/ https://www.tcl-lang.org/ (mirror). К сожалению не очень распространнён сейчас и многие имеют предвзятое мнение о нём. Несмотря на это используется очень широко и практически гарантированно что у вас на компьютере он присутствует. Возможно в составе диструбутива python, или как часть R или будучи встроен в иное приложение.

Из достоинств - стабильность API, и компактность (краткость) самого языка. Минимальный синтаксис и небольшое число команд https://www.tcl.tk/man/tcl8.6/TclCmd/contents.htm . Язык изучить очень просто. При этом «стандартные» библиотеки очень полезны и существуют технологии адаптации и использования других С библиотек(DLL) или взаимодействия с внешними программами.

Технологические проблемы которые несомненно ожидают - кодировка текстов. MQL использует 2-х байтный юникод, Tcl всегда utf-8. Любой текст передаваемый туда-обратно должен быть перекодирован. Ещё возможны трудности (потеря скорости) при работе с очень большими массивами данных. Например прямая конверсия массива double[] может повлечь создание множества объектов, по одному на каждый элемент. Статья пишется пост-фактум, и честно признаюсь, я боялся что в случае Tcl потеря производительности будет существенна и критична.

Материала набралось много, статья получилась длинной. При этом ещё есть многое что надо сказать и объяснить финальный выбор. Это очевидно уже в следующей части :-) Действительно слишком уже длинный текст и надо подводить промежуточный итог

Резюмируя вышесказанное - мы рассмотрели достаточно большую группу языков прграммирования с целью выбрать себе средство, которое может быть интегрированно в MetaTrader и будет дополнять MQL, для упрощения программирование и разработки торговых систем. Как ни странно, при всём богатстве и разнообразии современных технологий, у нас претендентов не так много :

  • mruby - вариация Ruby ориентированная для встраивания в приложения
  • lua - язык изначально проектированный как встраиваемый
  • tcl - «tool common language» сделан для объединения и расширения систем

При этом мы даже не сравнивали функциональные возможности - на этом этапе мы только отсеили заведомо неподходящие, сомнительные и излишне трудоёмкие решения.

Широкоизвестные «универсальные» и специализированные «вычислительные» языки отпали в процессе рассмотрения, они просто не для этого сделаны и не рассчитаны на применение подобное нашему.

Для многих это сюрприз :-)

далее - Заключительная часть статьи