Блог им. facepalm

[опрос] Платформа для алготрейдинга

[опрос] Платформа для алготрейдинга

StockSharp
AmiBroker
Metatrader
QUIK
TSLab
самописная на C++
самописная на C#
самописная на Delphi
самописная на Java
самописная на R
самописная на VB (Excel)
самописная на Python
самописная на другом ЯП
другое
Всего проголосовало: 97

Интересно, кто что использует.

Понятно, что варианты ответов могут не совсем правильно передавать суть. Т.к., например, StockSharp может использовать коннектор для QUIK.

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

В вариантах ответов не указал SmartCom (возможно, зря), поскольку, по-моему мнению, использование этой библиотеки ближе к варианту самописной платформы.
Данная публикация является личным мнением автора. Мнение владельца сайта может не совпадать с мнением автора.
134 | ★4
18 комментариев
Как новичек написал Amibroker, т.к.:
1. Программа простая для понимания
2. Внутренний язык простой. Тысячи примеров программ на официльном сайте. Я как не программист смог достаточно бысто изучить его и написать первого робота.
3. Хорошее русское сообщество на Amisite, где всегда помогут советом. Так, например, мне там помогли найти коннектор к R, чтобы в Amibroker использовать весь функционал R.
4. С помощью AmiSharp коннектится к Quik и работает стабильно. Из Quik можно получать тики. Пробовал запускать типа hft: если три последовательных тика увеличиваются, то покупаем на 4-м по рынку. Продаем также. В целом работает, но из-за скорости Quik имеется большое проскальзование. Так, что лучше реализовывать идеи на минутках и выше.

В целом. При использовании Amibroker проблема не в программировании, а в поиске идеи для системы.

Сейчас смотрю в сторону C# и S#.
avatar
vito2000, Поддерживаю)
avatar
Вы бы объединили все пункты про самописную. Потому что споры какой язык программирования лучше — это из «другой оперы». Тут «на вкус и цвет...». Ответ то в этом случае простой: на каком лучше получается, на том и пиши. Вот я, например, С# взял только потому, что имел опыт программирования на С++ под MS-DOS в конце 80-х-начале 90-х. Но сказать, что-то использовал из его новомодной объектной ориентированности, не могу. Единственное, что я освоил в нем новое — это закачку данных из базы данных.
avatar
А. Г., «Потому что споры какой язык программирования лучше»

Нет никаких споров.
avatar
professor facepalm,

Дело не в этом. Как уже написал, я использую С#, но не поручусь, что это лучше, чем самописная, например на R.
avatar
Присоединяюсь к мнению уважаемого А.Г.
Лучшая платформа для алготрейдинга та, с которой трейдер умеет эффективно работать.
Сам пока пишу на QLua, но активно изучаю C# (опять же в связке с квиком). Что будет через 5-10 лет? Доживем — увидим…
avatar
Коробочные решения — более универсальны. И, возможно, будут удобны для большинства алгоритмов. Вы сразу решаете проблему с тестированием и отладкой ядра.
Но универсальность иногда урезает необходмый функционал и скорость работы. Писать что-то свое нужно на этапе, когда есть четкое понимание что писать, как и для чего.
avatar
Alex Hurko, судя по картинке из профиля, на Python программируешь :) Причём используется какой-то локальный сервер с котировками, работающий по REST. В чём смысл? Почему взаимодейтвие не напрямую с БД происходит?
avatar
professor facepalm, на python только тестирую. Набросать алго там намного быстрее, нежели на C#. Ну во всяком случае мне:) На локалхост котировки отдает API датафида (ActiveTick), по многим причинам мне удобнее юзать HTTP запросы для закачки котировок в MongoDB. Дальше я работаю уже с БД. То, что торгуется в основном работает на C#. Меньше проблем с интерфейсом + API терминала на C#. Но кое-что есть торгующее из питона и экселя. Все зависит от задач.Нет смысла писать нечто громоздкое ради 5 сделок в неделю.
avatar
Alex Hurko, А вы же раньше вроде MultiCharts'сом пользовались что с подвигло на переход на собственную платформу?
avatar
Игорь, и сейчас пользуюсь. В любой связке есть тонкие моменты, ограниченные функционалом платформы. Увы, есть стратегии которые проще полностью переписать.
avatar
Alex Hurko, «Меньше проблем с интерфейсом + API терминала на C#»

Можно ведь коннектор написать. Тогда сразу после тестирования стратегии можно будет запускать python-робота на реальной торговле.
avatar
professor facepalm, можно. Но это костыль. Iron Python не очень удачное решение из-за скорости и отсутствия поддержки многих питоновских либ. А связка питон + либа + сишарп имеет ряд недостатков. Например, проблема с ивентами. и тд.
avatar
Alex Hurko, «А связка питон + либа + сишарп имеет ряд недостатков. Например, проблема с ивентами. и тд.»

Ну это скорее не проблема, а задача. Решается она без особых сложностей. Вариантов много. Один из самых простых — это использовать redis (in-memory key-value database). Если конкретнее, то: redis.io/topics/pubsub
Суть в том, что из python можно подписаться на сообщения в БД по определённому адресу. И когда C# будет отправлять туда данные, то на стороне python'а они будут автоматически появляться. Нужно лишь поверх этого спроектировать простенький протокол (например, на основе json'а).
Есть и другие варианты: zeromq, grpc (точно не уверен), rest-сервер с вебсокетами.
avatar
professor facepalm, это собственно позволеят также перенести разработку всего того, что связано непосредственно с торговлей, на линукс. Оставив на винде только часть, взаимодействующую с redis и api терминала. Если, конечно, разработка на линуксе имеет какое-то занчение.
avatar
professor facepalm, да, это все возможно. Просто зачем извращаться, когда есть полноценное АПИ терминала на C# и АПИ датафида на C#? )) Если работать без терминала под FIX, тогда и потребности в C# не будет как-таковой. Там уже выбор больше и в плане языков и плане ОС. Универсального решения я думаю что нет. Все зависит от потребностей, скоростей, функционала и тд. Если оно работает в вба, то пускай работает в вба, усложнять не нужно:)
avatar
Alex Hurko, «да, это все возможно. Просто зачем извращаться»

Затем, чтобы робота надо было только один раз писать и с тестов можно было сразу запускать на реальной торговле. Без переписывания с python на другой язык и привязывания к api терминала/брокера.
avatar
professor facepalm, в идеале звучит хорошо. Но у меня так не получается. Практически под каждый алго приходится писать свой движок. Алгоритмы очень специфичны, увы. Проблема одного движка в том, что поменяв одно — начинает сыпаться другое. Больше времени уходит на отладку и тд. Но у меня опять же очень специфичные алго, там нет buy on the next bar и тд. В каждом есть своя проблема, свой прсчет, свои данные… Поэтому я и начал с того, что нужно сначала коробочные решения поюзать. Но увы я не видел ни одного универсального решения, которое могло бы сразу покрыть хотя бы 60% моих потребностей. И сам я тоже вряд ли смогу запихать все в одну коробку. Как-то так.
avatar

Читайте на SMART-LAB:
Фото
Итоги первичных размещений ВДО и некоторых розничных выпусков на 7 октября 2026 г.
Следите за нашими новостями в удобном формате: Telegram , Youtube , RuTube, Smart-lab , ВКонтакте , Сайт ,...
Фото
Денис Баранов о вызовах и возможностях индустрии кибербеза
Во время главной пленарной сессии форума «Цифровые решения» представители ведущих ИТ-компаний страны вместе с Михаилом Мишустиным и...
Фото
Курс закончился. Что дальше❓
На курсе всё обычно выглядит проще. Есть преподаватель, разборы, примеры сделок. Вам всё разжёвывают :) Потом курс заканчивается, и трейдер...
Фото
Хэдхантер. Рынок труда в сентябре: hh.индекс снизился до 8,5 - становится лучше?
Вышла статистика рынка труда за сентябрь 2026 года (за август можно почитать здесь ), которую Хедхантер публикует ежемесячно, что же там...

теги блога professor facepalm

....все тэги



UPDONW
Новый дизайн