По моему опыту в алготрейдинге (под алготрейдингом я подразумеваю поиск закономерностей и их использование) большая часть времени уходит на исследования, это примерно 90% времени. Однако, часто можно услышать критику примерно следующего плана.
- Нужно писать код на питоне/джаве, можно в два счета набросать торгового робота. Нафиг Си и С++, сложна.
- Не нужно изобретать велосипеды, все уже сделано за нас. Зря потратить время, бери готовое и действуй. Метатрейдер в помощь.
- Нужно всегда писать чистый код, а не говнокод.
Если все это верно, то получается, что успех в алготрейдинге (да и в IT) должен зависеть от этих факторов. Однако, к примеру, на практике большая часть доли в проекте принадлежит обычно не программистам (т.е. людям, которые вообще могут не уметь программировать), хороший код не обязательно принесет много денег, да и сложные алгоритмы порой без разницы, на каком языке реализовывать, быстрее они не напишутся.
Если объяснить проще, то успех не равен чистоте, хорошести и прочим характеристикам кода. Тогда почему происходит акцентуация на подобные факторы?
В качестве примера, возьмем начальное условие, что известен алгоритм «грааля» (допустим, случайно попала инсайдерская информация), но навыков в программировании ровно как у вчерашнего студента. И ситуация наоборот: допустим, навыки программирования как у senior'a, за плечами лет 20 работы в разных крупных фирмах, но при этом в трейдинге — полный ноль.
Сдается мне, в первом случае шансов построить рабочую ТС куда выше. Да и по опыту общения с прогерами могу сказать, что тру программисты обычно не столь рискованные парни, чтобы идти в подобные проекты. Поэтому во втором случае история даже не начнется (скорее всего).
Поэтому, я бы выделил другие важные пункты в алготрейдинге (и не только в алго):
- Нужно уметь работать с переживаниями. Эмоции могут влиять на восприятие, заставлять принимать неверные решения, вызывать избирательность внимания, что в конечном счете может свети результат работы к нулю, даже если это исследования. В алготрейдинге стресса хватает, поэтому этот пункт актуален. Ошибаются все люди, но если есть адекватное восприятие реальности, то после ошибки можно продолжить эффективно работать над проектом. Если же переживания поглощают сознание, то тут уже ничего не сделаешь, все пойдет по неудачному сценарию, так как по факту нет контроля над ситуацией, даже над самим собой нет контроля.
- Важно вовремя соскочить с идеи, если становится понятно, что идея не несет в себе смысла. К примеру, можно угробить на нейросети несколько лет, пытаясь заставить их прогнозировать рынок. А можно, повозившись с нейросетями месяц-другой, прийти к выводу, что эта задача данным инструментом просто так не решается, и приступить к другим исследованиям.
- Не путать скептицизм с предвзятым негативным мнением. Риск может быть уместен. Впрочем, данный пункт все алготрейдеры скорее всего соблюдают, иначе не пошли бы в данную сферу деятельности, а прислушались бы к мнению большинства.
- В разработках нужно уметь не зарываться в сами разработки, важен результат. Поэтому говнокод порой уместен.
- Если речь идет про создание достаточно сложной системы, то писать много кода придется в любом случае, и разница между Си, С++, джавой, питоном тут будет стираться. Если это высокочастотная торговля, то конечно выбор очевиден. Но в других случаях может показаться, что проще будет работать в более «простых» языках. На самом деле, если есть хоть какой-то опыт в программировании, то мне кажется что язык программирования не столь важен, он за вас сложный алгоритм не распишет и всю систему не выстроит. Гемороя будет в любом случае много, а современные языки во много схожи между собой, имеют схожий синтаксис. Не думаю, что тут есть принципиальная разница. Кто начал с питона, тому проще будет на питоне. Кто начал с Си, тому проще будет дальше на Си. Разве что для питона много библиотек для машинного обучения.
- Велосипед конечно не всегда нужен. Но на практике, если велосипед небольшой, на него не уйдет много времени, и уж точно он не станет черной дырой проекта, потому что черной дырой являются исследования закономерностей, которые могут при желания растянуться до бесконечности.
Лично я опыт в крупных фирмах не считаю, там в основном заняты политиграмы нежели поднятия квалификации.
За день можно кучу алгоритмов перебрать, много бесполезных, и писать их на Си… Ну не.
И это стандарт в мировой индустрии
А если просто брать библиотечки и ваять что-то простенькое и пробовать — ничего серьёзного так найти нельзя.
Это тоже глубокое заблуждение ))
Процитирую целиком лучший пост на эту тему из уважения к героям прошлых лет (2012 год):
Сказка о феях Эпиграф:
В трейдинге как и в любой деятельности, которая связана с исследованиями, часто возникает ситуация, когда направление дальнейших действий неизвестно и не определено. Соответственно из этого положения человек начинает искать выход основываясь на своем бэкграунде и опыте.
Конечно для любого трейдера необходимы знания софта, и хотя бы одного языка программирования.
Но речь в сказке пойдет о тех, кто уже имеет достаточно опыта торговли, создания систем, и знаний.
Так вот приходит такой трейдер в творческий тупик, и начинает сразу думать о путях выхода, и как правило речь идет не о том, чтобы искать решения в себе. А о поиске внешних средств, несколько простых кейсов, чтобы было понятно о чем я:
1. Excel медленно считает, нужно написать свою программу для расчетов
2. Эх, если бы у меня была программа Х я бы натянул рынок, не то что с этой программой Y
3. У меня не получается торговать руками, но вот если купить робота за 3000 рублей, вот тогда я стану богатым
4. Хранить историю котировок в текстовых файлах не кошерно, надо придумать свой формат сжатия
5. Программа Z не умеет тестировать тот класс стратегий, что мне надо напишу ка я свой фреймворк/бэктестер/терминал для этого
6. А напишу ка я свой бэктестер, потому-что свой, потому-что удобнее и не то что у других
Все это, господа — секс с феями. Все трейдеры в душе перфекционисты, все хотят быстрее, выше, сильнее. Но время — ресурс невосполнимый, и тратя его на одно дело, мы забираем его у других. Поэтому я оглянулся назад и оценил, сколько работы я сделал зря ради красоты и перфекционизма. Многие проекты были заброшены сразу после того как доведены до стадии какой-то работоспособности. Мне стало грустно, конечно опыт остался, очередного робота(order management system) или бэктестера я могу за пол месяца написать на хорошем уровне, но не хочу!
Поэтому выработал для себя несколько правил:
1. Если проблему можно решить за 1 день, написав под это узкую программу, или за 30 дней, написав под это фреймворк. Нужно писать узкую утилиту, потому как есть вероятность, что больше никогда к этому не вернешься. Однако и утилиту можно сделать гибкой.
2. Если чешутся руки создать что-то глобальное и красивое, задайся вопросам а науха это надо? Какую конкретно задачу это красивое-доброе-совершенное будет решать, и сколько бенефита оно принесет? Если задача все равно важная, см. п. 1.
3. Если при решении задачи возникает желание создать что-то глобальное, с формулировкой, например «а хорошо бы иметь свой бэктестер» — значит задача поставлена неверно, или слишком общО сформулирована.
4. Если задачу можно сделать как-то через жопу имеющимися средствами — делай через жопу
5. Всегда стараться сократить время на решение задачи путем повышения эффективности. Если есть 100% уверенность повторяемости действий, нужно делать фреймворк. Но не нужно писать новый Амиброкер или Омегу, нужно делать только то, что даже через п.4 не делается. Если решился делать фреймфорк, делай масштабируемую архитектуру (напр для роботов-исполнителей), но реализовывать нужно только, то что потребуется здесь и сейчас для решения задачи.
6. Для каждого гвоздя должен быть свой микроскоп! Глупо тестировать торговые системы на ассемблере, глупо делать двойную работу переписывая алгоритмы в разных платформах, глупо писать свое если есть уже готовое.
Я так понимаю, что его:
https://smart-lab.ru/profile/ubertrader/
Очень жизненно!
Касательно синтаксиса мне кажется, что неудобство компенсируется умением пользоваться конкретным языком. Поэтому некоторое время спустя это должно особо не чувствоваться.
С библиотеками — да, в С++ геморрой есть их прикручивать. Однако после того, как библиотека подключена, начинается действительно самый сложный этап — работа над самим проектом. Не зря же шутят, что после 99% проекта начинается еще одни последние 99% проекта. Все тут зависит от сложности. Если, скажем, кодить прилагу под смартфон, то ясен пень лучше писать основной код на джаве, а не на С++. Если же кодить нейросети, то после этапа «я подключил библиотеку» по идее сложность одинаковая, какой язык не возьми.
Видимо поэтому ваш блог заполнен разными индикаторами )))
Уровни и кумулятивная дельта — тоже не использование закономерностей?
Вы либо бредите, либо вводите в «глубокое заблуждение».
А вы уже забыли о чём ВЫ писали, на что я отвечал…
И будто не видите о чём я спросил, занимаетесь демагогией.
Вы действительно далеки… от рынка.
1% за «умеете» — это оставляю на везение, оно может быть и 19 лет.
А я с вами согласен — успех в алготрейдинге зависит больше от алгоритма, чем от его реализации в коде (чистоты, «тяжести»).
На мой взгляд это очевидно.
Так что в действии бритва Оккама «Не следует множить сущее без необходимости»
Eugene Logunov, я бы не стал использовать такую библиотеку.
А если серьезно, не вижу современных языков, позволяющих на уровне команд проводить множественное разветвление процесса оценки критерия с дальнейшим копанием каждой ветки (ну. типа ЛИСПа). Кто знает, подскажите.
Проще писать на С#/Java благодря довольно большому количеству реализованных классов в SDK и большому количеству имеющихся библиотек и довольно просто работе с памятью. Ну или на JavaScripte c NodeJS.
для вас это прежде всего набор готовых библиотек и сборщик мусора