Alexey_Donskoy писал(а):
facevalue писал(а):
Программировать можно "без проблем" и на фортране. Только популярность визуальных конструкторов вызвана как раз тем, что программировать ничего не нужно.
Согласен.
Почему я высказался именно про программирование?
Потому, что исторически большинство инструментов предназначались для программистов (или, как минимум, квалифицированных специалистов), которым, по большому счёту, рюшечки визуального программирования не очень важны (а иногда даже мешают).
Думаю, что именно в этом и есть объяснение сложившейся ситуации.
Верно, для квалифицированных специалистов. Торговлю саму мало знать, нужно разбираться еще и в этом софте. Он и сейчас не для новичков. Подход Дракона многое бы изменил.
Цитата:
Цитата:
А кто мешал Древним Римлянам кататься на ДВС или запустить какую-то ракету в космос?
Вопрос, имхо, некорректен. Ибо визуальному программированию примерно столько же лет, сколько и биржевому. Техническая возможность соединять квадратики была всегда, просто никто не считал это достаточно нужным.
Согласен отчасти. Визуальное "программирование" роботов появилось как идея сравнительно недавно. Еще "недавнее" - среды разработки. Но я почему спросил про Древний Рим - для того, чтобы какая-то идея ожила, ее существования недостаточно. Нужно развитие и "евангелизация" нового мышления. Тогда появится шанс увидеть что-то новое. Например, что Земля таки круглая. Или что алгоритмы можно складывать не из кучи кубиков, а можно на вход подавать все желаемые условия, и потом выстраивать логику. Вроде бы простейшая очевиднейшая вещь! Но ни одна платформа визуальной разработки этого сейчас не делает. NONE. Почему? Потому что никто так не думает! Нет такого стандарта мышления.
Цитата:
Цитата:
WealthLab стал законодателем религии визуальных алгоритмов.
Подобных примеров в технике и особенно в IT можно привести множество. Совершенно типичная ситуация, что крупные игроки своим весом формируют неофициальный стандарт отрасли (а затем и официальный проталкивают).
А в результате мы имеем тот же Windows на ПК и кучу других слабых и уязвимых для критики решений.
А где смайл с аплодисментами???!!! )))))) В биржевом мире эта проблема тоже есть, от торговых терминалов до протоколов обмена данными (FIX-protocol). Причина - итак работает, все привыкли. Но появление новых сред становится очень популярным, потому что раньше 80% трейдеров не покидали Манхеттен. Сейчас 85% трейдеров сидят дома и понятия не имеют что такое биржевой стандарт. ) Благодаря им и появились визуальные среды разработки.
Цитата:
Цитата:
Если бы я знал все это в 2011-м, то все проекты можно было бы реализовать
не за полгода, а за пару месяцев максимум.
Повторю, что такая оценка мне представляется необоснованно оптимистической.
Я объясню, все просто. До Дракона, на обычных "пальцах" или ЮМЛ, пишется алгоритм. Потом кодится. Все это естественно не работает с первого раза. И никто уже на ЮМЛ не смотрит. Копается код. Переделывается пять раз. Потом как правило все упорядочивается, пишется новый код, без костылей. Он уже работает, но естественно не так, как должен, not as expected. Идет багфикс, плюс в процессе появляются новые идеи, которые превращаются в новые костыли... Дата продакшна - страшный сон программистов. И это все время. Не одного дня время.
На Драконе сейчас запущен пилот: отдельный кодер, отдельный алгоритм. Он, собственно, представлен выше. Там нет магии, вся магия в самом спреде.
Так вот... Вместо обычного пути разработки все было "загнано" под Дракон. И код не ковырялся, костыли не писались. Кода вообще не было, пока я не утвердил схему.
В чем разница? В ЮМЛ черт ногу сломит, раз. Два - логика построения ЮМЛ не помогает, а
способствует допущению ошибок. Три - ЮМЛ и обычные блок-схемы создают иллюзию полноценной картины, на практике оказывается все совсем иначе.
С Драконом не так. Сама логика другая. Это как другая форма жизни с похожими ДНК. В процессе построения ошибки лезут
сразу. Если что-то в алгоритме не продумано до низкого уровня (вопрос - ответ да/нет), это видно сразу. Благодаря этому же принципу идеи и наработки появляются в процессе работы над БС,
а не над кодом. В итоге, программист действительно становится дорогим расходником. "На бумаге" появляется прозрачный алгоритм БЕЗ разночтений. И последняя работа выглядела так - я неделю работал над базовым рисунком, потом мы его два раза обсуждали, я внес дополнения, сделал две версии, и программист СРАЗУ написал РАБОЧИЙ ИЗНАЧАЛЬНО код. Он сам не поверил, что это произошло. Мелкие багфиксы были связаны уже с его реализацией протокола обмена данными и отправкой/получением заявок. Это был еще один день. Два дня тестов - вуаля. Весь процесс - три недели. Раньше это заняло бы не меньше двух месяцев. И от уровня разработчика/кодера это не зависит.
Биржевые разработки отличаются от всех других. Всех-всех. Обычное ПО статичное, квадратное. Его можно разработать на бумажке, и оно будет работать. Биржевое ПО имеет дело с постоянно меняющимися данными. В миллисекунду можно запихнуть столько всего, ууу... И как правило, разработка на бумажке не работает. В больших высоких небоскребах эта проблема решается брутфорсом - много-много программистов. В случае простых смертных вроде меня это решается ценой больших временных затрат. С появлением Дракона
как стандарта, а не как дара мыслить прозрачно или как опыта некоего разработчика, меняется расстановка сил. Возможности совсем другие. Скорости сразу другие. Повторюсь, отдельно взятый кодер может обладать сверхопытом и даже нобелевским мышлением. Но моя задача -
максимально избежать зависимостей от таких людей. Дракон позволяет это сделать.
Цитата:
Цитата:
Видно, что Вы не сталкивались с торговыми алгоритмами
Видно, что вы излагаете предвзятое мнение, что вполне коррелирует с предыдущим пунктом
Таки я занимался немного торговыми алгоритмами, хотя было это уже полтора-два десятка лет назад...
С тех пор много воды утекло... Посмотрите quantitative trading, high frequency trading, market-neutral strategies. А по поводу предвзятого мнения - вряд ли. К чему предвзятость? Более того, мнением оперируете Вы. Я оперирую как раз опытом разработки последних пяти лет в разных командах и проектах с учетом вызовов современной биржевой торговли. Может это не самый лучший опыт в мире, но он мой и он реальный.
Цитата:
...Напомню, что ДРАКОН - это всего лишь ряд дополнительных ограничений на стандартную алгоритмическую форму записи...
Вот этот ряд все меняет! Может для Вас нет разницы. Это одна из проблем "евангелизации" - все думают, что ничего нового.
Этот ряд исключает допущение ошибок. Может при разработке какого-то суперсложного софта Дракон и будет слаб, не знаю. Хотя Буран летал, Тополь-М тоже не списывают. Для биржевых операций эта форма логики, с этими
дополнительными ограничениями,
создает абсолютно другую форму жизни. Маленькие изменения в ДНК отличают шимпанзе и человека. Даже в утробе все изначально похожи. Но на выходе получается или человек, или шимпанзе. Или мутант
. Тоже самое с алгоритмами. Вроде ничего нового, так, пара ограничений. А на выходе - разный результат.
Цитата:
Вопрос по существу: достаточно ли только алгоритмического языка для складывания стратегии из блоков?
Я, например, экспериментировал с другими формами (FBD) и нахожу, что для генерации торговых сигналов эта форма удобнее алгоритмической.
Для других задач? Пока не знаю, практики действительно маловато.
Function Block Diagram? Напоминает упрощенный ЮМЛ... Или ошибаюсь? Но опять таки, Те Самые Ограничения, которых нет на FBD, делают последнюю плохо читаемой.
Алгоритмический язык нужен для построения логики, для единого обмена информацией между разработчиками алгоритмов и программистами. Если разработку делать самому и для себя, то никакой стандарт не нужен - сам себе царь. А если говорить о командном заплыве, то без этого очень сложно. Я бы сказал, что невозможно. Разница между всеми другими и Драконом тут очевидна.