Уважаемые разработчики!

Есть предложение по редактору скриптов. Но прежде чем его сформулировать, поясню...

Визуализация в редакторе скриптов одновременно всех связей, или как вы их называете соединителей, совсем не способствует прозрачности разрабатываемого алгоритма. Более того, такой всеобъемлющий показ блочных связей только мешает пониманию назначения как каждого блока в отдельности, так и скрипта в целом. Как известно, программы не столько «пишутся», сколько «читаются», именно поэтому в языках программирования приветствуется все, что способствует их пониманию (отступы от начала строки, цветовое выделение различных элементов языка и т.п.). Применительно к TSLab, удаление многочисленных внеблочных связей только повысит читабельность графических схем в редакторе скриптов. Есть еще одна причина. Дело в том, что человек не может удержать в голове более 5-7 связей, все что свыше или просто не воспринимается (но тогда зачем их показывать?), или хуже того, просто мешает воспринимать анализируемые связи. Я соглашусь, что полный показ всех связей способствует пониманию только очень простой торговой системы, реализуемой из небольшого числа кубиков (5-7). Но разработка более-менее серьезной ТС, состоящей из нескольких десятков блоков, превращается в настоящую головную боль, когда за деревьями (связями) не видно леса (ТС), а графическое представление скрипта больше напоминает любимое итальянцами блюдо – спагетти

Предложение.

Добавить в редакторе режим «Спагетти Выкл.». В этом режиме редактор отключает визуализацию всех связей, оставив для показа только те связи, которые относятся к выделенному блоку, на котором в данный момент наведена мышь. Это позволит последовательно, шаг за шагом, (от блока к блоку), анализировать и проверять алгоритм проектируемого скрипта, не путаясь в многочисленных «внеблочных» связях. Кроме того, при размещении конструируемых блоков это позволит не заботиться о минимизации многочисленных пересечений «соединителей», полностью концентрируясь на алгоритме ТС. В настоящее же время задача по конструированию алгоритма в визуальном редакторе постоянно соседствует с задачей, возникающей при проектировании печатных плат – минимизация связей.

Впрочем, чтобы не обидеть другую группу разработчиков алгоритмов, которые в состоянии воспринимать более 7 связей одновременно, предлагаю оставить и текущий режим «Спагетти Вкл.».

Так всё так практически и выполнено - связи выделенного блока высвечиваются яркими ( если так можно сказать о черном цвете :-),
а не относящиеся к блоку - бледно серыми.
По-моему оптимально..

тоже особо не путаюсь в "соплях" связей между кубиками, применительно к своим скриптам. Потому что логика всегда заранее обдумана и понятна, от неё собственно и начинаем писать. А вот разобрать чужие.... в чужих даже и не пытаюсь разобраться, потому что это задача от обратного: смотря редактор, понять чужую логику.
Вопрос только насколько это актуально....
Есть один способ: кубик в котором запутались вытаскиваем за общее поле и смотрим связи, последовательно подтягивая и ставя рядом зависимые и влияющие кубики.

С выходом версии 1.2 многие подобные вопросы, как я понимаю, будут сняты. Кто знает, может даже рабочее пространство визуального редактора станет 3D))

Да, выделение внебрачных внеблочных связей бледно-серым цветом действительно приближает нас к поставленной цели, но окончательно ее не достигает! А цель у нас архиважная - оставить и усилить в редакторе все, что способствует пониманию визуального представления логики и структуры скрипта, и наоборот, отключить или уменьшить влияние тех элементов визуального редактора, которые не способствуют или мешают такому пониманию.

На мой взгляд, совсем не оптимально таскать по всему рабочему пространству визуального редактора этот клубок связей, это только грузит и мозг и процессор бестолковой работой по отслеживанию однажды установленных (а значит существующих, никуда не исчезнувших) связей.

P.S. Впрочем, как вариант, чтобы сделать потусторонние связи, т.е. связи, не имеющие отношения к выделенному блоку, невидимыми, можно попробовать рисовать их, например, белым по белому или черным по черному. Для начала можно сделать и так, чтобы оценить востребованность режима "Спагетти On/Off". Название, конечно, условное, окончательное название этой опции, как всегда, остается за разработчиками, если, конечно, сама опция будет воспринята ими с пониманием.

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

Да, действительно, в случае проблем с каким-то кубиком, нам ничего не остается, как таскать его из угла в угол, как Тузик грелку , пока мы не локализуем ошибку. Но для чего мы это делаем? Да чтобы изолировать этот кубик от других, что позволит быстрее найти и устранить эту ошибку. Только вот вопрос - а зачем вообще таскать кубики, прежде чем приступать непосредственно к поиску ошибки. Почему нельзя отлаживать скрипт без перетаскивания кубиков? Ответ напрашивается сам собой: связи не дают!

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

... и тогда процесс визуального конструирования скриптов в 3D-пространстве будет еще больше походить на проектирование многослойных печатных плат, а это уже в свою очередь, потребует разработки САПР-С, системы автоматизированного проектирования скриптов...

Много всего написали :-)

Как дополнение Вкл-выкл связи мысль дельная. Мы подумаем.

В планах будут вестись работы по улучшению визуального редактора. Тут главное не перемудрить. Многие привыкли к тому что есть. Основная идея доработки, должен появится способ группировки многих блоков в один. Как вы верно заметили для удобства построения сложных алгоритмов.

буквально сегодня столкнулся с данной проблемой - необходимо проверить 60 кубиков ( где то ошибка)....глаза в кучу, а результата нет. Хотя более простой скрипт ( основа для компилированного скрипта )работает без ошибок)))
поддерживаю связи ( вкл выкл)!!! в т.ч. и в редакторе))))
Хотя наверное альтернатива - монитор 2 М....

Если будет предложено мудрое решение по доработке визуального редактора, то те, которые привыкли к тому что есть, также быстро и отвыкнут. Целью добавления визуализации к процессу разработки и отладки алгоритма может быть только улучшение таких показателей, как время, затрачиваемое на разработку, отладку и сопровождение алгоритма, повышение читабельности и отчуждаемости скрипта и др. Если эти цели не достигаются с введением визуализации, то такая визуализация - сомнительный козырь перед простыми текстовыми редакторами скриптов.
Кстати, если бы в TSLab, наряду с визуальным редактором скриптов, существовал бы и простой текстовый редактор, то, на мой взгляд, это было бы лучшими решением для разработки сложных алгоритмов. Конечно, для этого потребуется формализовать язык, на котором можно будет описывать блоки и связи между ними, написать компилятор с этого языка. Но, для вас это было бы более быстрым способ предложить инструмент для разработки скриптов любой сложности, а с другой стороны, это сразу бы привлекло в ряды пользователей TSLab людей, привыкших пользоваться клавиатурой, а не мышью, используя старую как мир технологию copy-past. На этом пути сразу же открываются возможности по интеграции готовых кусков программ, написанных на c# в скрипт. А если вы еще напишите конвертор из текстового представления скрипта в графическое представление скрипта и обратно (*.xml <=> *.txt), загрузку и выгрузку скриптов из/в *.txt файлы, то...

Для примера, скрипт на таком языке (в текстовом представлении) мог бы выглядеть примерно так (кстати соединительные связи здесь отпадают сами собой):

Source1: Источник (GZM1, Левая панель1);
Source2: Источник (LKM1, Правая панель1);
Low1: Минимум (Source1, Левая панель1);
Stoch1: StochK (Source2, Левая панель1);
...
BuyLimit1: Открытие если ниже(Source1, покупка, 1);


Впрочем, возможно у вас в планах есть более радикальные решения по улучшению визуального редактора, когда будет удобно разрабатывать и сложные скрипты тоже.

Учетки перепутал?)

yes

Хотелось бы, например, и такое решение на будущее, что бы спагетти не мешали: выделить область (ту, например, с которой в данный момент не работаем) в скрипте и сделать отдельным кубиком выделенное. Тогда это будет как бы запертым слоем и не мешает писать дальше. Если возникнет необходимость, то кубику возвращаем первоначальный вид области. это позволит писать сложные скрипты с большим объёмом элементов и делать заготовки стандартных решений.

Я об этом писал выше.
------------------------
Основная идея доработки, должен появится способ группировки многих блоков в один. Как вы верно заметили для удобства построения сложных алгоритмов.
------------------------
Сделаем.

Спасибо, очень ждём

Мне кажется этой задаче должен быть присвоен разработчиками высокий приоритет.
Многие полагаю за этот год пришли к ситуации, когда остро необходим синтез отдельных наработок, а инструмент мягко говоря, оставляет..

Дело не в приоритете. Он высокий.
Дело в придумать и сделать красиво.

Не думаю, что удобство построения сложных алгоритмов - вещь субъективная, и может по-разному восприниматься большинством разработчиков. Идея визуализации – безусловно, замечательная идея, которая выгодно отличает TSLab от других сред разработки ТС, что позволило сразу привлечь большое число пользователей TSLab, в том числе не знакомых с программированием на C#. Если поделить всех TS-лаборантов на группы в зависимости от умения программировать на C# и сложности разрабатываемых ими ТС, то получается такая картина:

1 группа – немногочисленная, но наиболее профессиональная, это разработчики сложных ТС на языке программирования C# + API, которые если и заглядывают в визуальный редактор, то только для того, что собрать проект целиком.

2 группа – многочисленная, но наименее профессиональная, это в первую очередь новички, недавно познакомившиеся и с трейдингом и с ТА, которые в восторге от визуального редактора, позволяющего с легкостью построить ТС на основе пересечения двух скользящих средних.

Но есть еще 3 группа – достаточно многочисленная и достаточно профессиональная, не чурающаяся программирования, имеющая и опыт торговли, для которой возможностей визуального редактора явно недостаточно, а освоение C# + API – на данном этапе, слишком трудозатратно.

Мне кажется, что для 1-ой и 2-ой группы разработчики TSLab сделали все, что им необходимо, а вот для 3-ей группы – могли бы принести огромную пользу, предложив некий скриптовый язык и простой текстовый процессор для разработки ТС на этом языке.

Тот, кто способен сформулировать торговую идею, априори способен на большее, нежели на механическое перемещение десяти кубиков из угла в угол, и отслеживание связей между ними. К сожалению, один из законов психологии просто не позволяет удерживать в голове более 7 связей. Принцип же модульности (группировка многих блоков в один), как один из способов борьбы со сложностью проекта, к сожалению, не реализован в визуальном редакторе. А если и будет реализован со временем, то не сильно поможет, поскольку потребует дополнительных усилий на борьбу со сложностью визуализации самой модульности…

Не секрет, что концепция визуальной разработки есть не что иное, как концепция RAD (от англ. Rapid Application Development - быстрая разработка приложений), в которой особое внимание уделяется быстроте и удобству разработки приложений, созданию технологического процесса, который позволяет разработчику максимально быстро создавать приложения, в нашем случае скрипты.

В TSLab почти все есть: есть график, который появляется после внесения изменений в скрипт и нажатия на кнопку «Выполнить», это и есть настоящая визуализация! Осталось предложить скриптовый язык и текстовый редактор для него. Сделал изменения в текстовом редакторе, добавил строчку в скрипт, нажал на кнопку, и тут же увидел изменения на графике. Это и есть настоящая ВИЗУАЛИЗАЦИЯ. Чего же больше? А визуальный редактор – это все от лукавого, шкура выделки не стоит…

У нас есть идеи в этом направлении. А именно, введение смеси визуального редактора и скриптового языка. Однако пока это только концепция и вряд ли стоит ожидать в следующей версии. Но в этом направлении мы работаем. То что визуальный редактор - это от лукавого мы не согласны. В этом подходе есть свои преимущества. Однако наличие скриптового языка позволит разгрузить некоторую монструозность конструкций в визуальном редакторе.

Который раз вновь появляющиеся "оракулы" пытаются лишить ТСлаб одного из ее главных составляющих и преимуществ.
"От лукавого" - это имхо непродуктивные попытки утащить визуальное программирование в сферу формализованных строк "птичьего языка"..
Но ведь это же есть - и СИ и АПИ, есть желание и возможности ну и как говорится на вражьем языке - ВЕЛКАМ!
А встроенный визуальный редактор - эта штука пока вне конкуренции, к тому же в развитии ипонятно куда должна развиваться..
Что же касается возможностей подобного языка - посмотрите это -

Язык FBD (Functional Block Diagram, Диаграмма Функциональных Блоков) является языком графического программирования
Язык CFC
Язык CFC (Continuous Flow Chart) - еще один высокоуровневый язык визуальногопрограммирования. По сути, CFC - это дальнейшее развития языка FBD. Этот языкбыл специально создан для проектирования систем управления непрерывными технологическими процессами.

Задачи, решаемые с помощью данных языков, в том числе скромно замечу в своё время при участии вашего покорного слуги по сложности уж во всяком случае сопоставимы с трейдерскими, а по сути гораздо...

Это было бы уж совсем оптимальным решением предложить пользователям на выбор в каком редакторе предпочтительнее работать: в текстовом или в визуальном. Хотя и сейчас уже не трудно догадаться, что визуальный редактор будет использоваться для разработки несложных ТС, а также для учебных целей. Для разработки же ТС произвольной сложности - народ однозначно предпочтет скрипт.язык и текстовый редактор для работы с ним! Вот тогда и наступит настоящий "биполярный" мир, дружба и согласие между различными разработчиками, когда один пишет на скрипт.языке, а другой понимает, что он хотел сказать на нем, какая торговая идея воплощена в этом скрипте... Сейчас этого добиться практически не возможно при количестве блоков > 10.
Остается пожелать вам удачи и скорейших успехов в борьбе с "визуальным монстром"

Конечно тяжело разместить и соединить на поле всё что больше 10 блоков, ну если не 10, то 100 уже сложновато. разработчики обещали функцию объединения группы блоков в один, что существенно облегчит визуальное редактирование.

не лишить, а дополнить TSLab другим преимуществом - наличием выбора для работы в визуальном или в текстовом редакторе. Согласитесь, что "лишить" и "дополнить" - это все-таки разные вещи.

есть огромное кол-во продуктивных попыток использования скрипт.языков для разработки ТС, они слишком хорошо известны. К тому же речь идет о скрипт.языках, которые не есть тоже самое, что и C#+API, как Вам показалось.

... соглашусь, но добавлю - для разработки ТС ограниченной сложности, а также для учебных целей.

Эк Вас куда занесло, Вы бы еще вспомнили универсальную машину Тьюринга. Все упомянутые Вами языки являются узкоспециализированными, широкой публике не известными и малопользуемыми, к тому, если уж быть до конца честными, на поверку оказываются просто "мертвыми" языками. Никто же не станет в здравом уме и твердой памяти рисовать блок с двумя стрелочками слева и одной справа, а внутри блока рисовать знак "деления" - и это всего лишь для того, чтобы поделить одно число на другое. Для этого есть простая, понятная и общепринятая запись: x:y=z

Так что, на мой взгляд, единственно верный путь развития TSLab - в единстве двух подходов, или как сказал сам великий Nektodron: "в смеси визуального редактора и скриптового языка".

Да не, интересно конечно. можно и так попробовать. кому то подойдёт, кому то нет. не знаю только пойдут ли на такое разработчики. и так актуальных задач завалы.

Еще как подойдет! И пойдет и поедет, что называется на "Ура!". А разработчики уже думают над концепцией, и хоть и не в следующей версии, но обещали устранить имеющийся перекос в сторону визуальности, или, выражаясь их же словами: "разгрузить некоторую монструозность конструкций в визуальном редакторе".