«Зачем применять для JavaScript идеологию Питона?»
Чтобы потом понимать написанный код. Но этот вопрос не относится к языку ДРАКОН. Как хотите, так и пишите. Другое дело, что текущие реализации ДРАКОНа не позволяют нарисовать алгоритм в алгоритме. Это да. Поэтому в замыканиях только текст, а не графические примитивы.
«замыкание вам придётся иммитировать глобальными переменными»
Не придётся. Замыкания работают, как обычно.
Идеология как в Питоне. Нетривиальные лямбды не применяются.
Если требуется нестандартная лямбда, выносите алгоритм в отдельную функцию и вызывайте эту функцию в лямбде. app.drakon.tech/ide/doc/drakon-tetris/89 app.drakon.tech/ide/doc/drakon-tetris/31
Обоснование: вложенные алгоритмы красивы и элегантны, но их не всегда удобно читать.
«Microsoft Flow — это такой доработанный дракон.»
Шутка удалась. :)
Если серьёзно: чем Flow хуже дракона? Почему Flow недоработан?
1. Из-за отсутствия шампура (центральной линии алгоритма) слишком много изгибов.
2. Нет силуэта. В результате схемы растут слишком далеко вниз. А в силуэте одна ветка на экране помещается.
3. Сам геймплей редактора муторный: трудно перекидывать ветки, копировать-вставлять и так далее.
Но несмотря на эти мелочи народу нравится Flow.
Вы совершенно правы здесь, не спорю. Говорю только, что на практике это обычно не проблема. Больше того, абсолютная симметрия путей — редкость. Есть всегда какая-то шняга, и она уходи вправо: пустой массив, null, ошибки, ещё что-то.
Но иногда уходить вправо заставляет топология схемы — иначе не сложишь. Тогда да, читатель ожидает проблем, а там всё хорошо. Правило тогда мешает.
«диаграмма читается лучше, чем не диаграмма» — это известная вещь, старая проблема.
Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.
А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?
«Пожалуйста, ссылку на конкретное исследование.»
Ищите сами. Автор статьи даёт знания. Нужны вам эти знания или нет — это ваше личное решение.
Да, это верное замечание. Но на практике это не проблема. Если есть throw или error — кидаешь их в правой части схемы и всё.
С другой стороны, ассимметрия довольно часто бывает.
Строгих доказательств лёгкости восприятия у меня нет. Только личный опыт и опыт людей, с кем работал. Если вам интересно — собирайте доказательства сами.
А вот с формальным обоснованием «лёгкости» всё в порядке. В основе ДРАКОНа лежат объективные правила эргономики. «Объективные» — значит не важно, нравятся они вам лично или нет, знаете вы о них или нет. Работают и всё. О них можно прочитать, всё гуглится. Примеры: запрет на пересечение линий, только прямоугольные двумерные графы, требования по выравниванию ширины и расстояний, предсказуемость (следующий элемент — внизу), единообразие (ветвление только вправо), правило «общая судьба», правило «чем правее, тем хуже», чёткое выделение циклов и прочее.
Microsoft Flow взлетел, и ещё как. Людям нравится. А ведь Microsoft Flow — это такой недоработанный ДРАКОН. Кстати, я общался с сотрудниками Microsoft за пару лет до того, как включили мощное продвижение этого самого Flow. Сотрудники говорили мне: «Microsoft против визуального программирования, только текст». Обманули.
Функциональное программирование и ДРАКОН не противоречат друг другу. Наоборот, писать на функциональных языках (или в функциональном стиле) при помощи ДРАКОНа очень даже приколько.
Это правда, часто сценарии равноправны.
Правило «чем правее, тем хуже» позволяет выделять неприятные сценарии (например, обрабоку ошибок).
Позволяет, но не заставляет. Если сценарии равноправны, правило не применяем.
«Но зачем обсуждать алгоритмы с теми, кто не может читать код?»
Потому что те, кто не может читать код, дают деньги на разработку.
«почему бы в таком случае не обойтись русским языком, без блок-схем?»
Просто русский (или английский) не потянет — слишком сложный сейчас софт. Текст приходится структурировать в виде юз-кейсов. Но с юз-кейсами возникает проблема — повторы. И тогда видишь: да, надо было брать ДРАКОН с самого начала.
ДРАКОН — правила рисования блок-схем.
Эти правила не случайны. Они составлены так, чтобы выжать максимум из графического представления алгоритмов. Что дают эти правила?
1. Легкость восприятия (примеры: запрет на пересечение линий, только прямоугольные манхеттен-графы).
2. Единообразие и предсказуемость (примеры: следующий всегда внизу, ветвление всегда идёт вправо).
ДРАКОН исправляет:
1. Бизнес-процессы (жизнеритмы). В отличие от должностных инструкций, диаграмм BPMN и прочего, ДРАКОН отвечает исполнителю на вопрос: Что конкретно мне делать сейчас?
2. ТЗ. ДРАКОН объясняет, как работает эта хрень.
Есть иконы "Ввод" и "Вывод". Применются для обозначения приёма и посылки сообщений.
Есть икона "Полка". Там в верхней части обычно пишут исполнителя (если их несколько). Но можно написать отправителя и получателя сигнала. Например: Браузер > Сервер приложения
Вот так
Но это ДРАКОН, язык. DRAKON Editor (софт) не поддерживает на данный момент некоторые фичи языка ДРАКОН. Поэтому я прибегаю к ДРАКОНовским конечным автоматам для такого.
Это в следующей статье.
Чтобы потом понимать написанный код. Но этот вопрос не относится к языку ДРАКОН. Как хотите, так и пишите. Другое дело, что текущие реализации ДРАКОНа не позволяют нарисовать алгоритм в алгоритме. Это да. Поэтому в замыканиях только текст, а не графические примитивы.
«замыкание вам придётся иммитировать глобальными переменными»
Не придётся. Замыкания работают, как обычно.
Если требуется нестандартная лямбда, выносите алгоритм в отдельную функцию и вызывайте эту функцию в лямбде.
app.drakon.tech/ide/doc/drakon-tetris/89
app.drakon.tech/ide/doc/drakon-tetris/31
Обоснование: вложенные алгоритмы красивы и элегантны, но их не всегда удобно читать.
Это визуальный язык алгоритмов. Математика + эргономика.
Шутка удалась. :)
Если серьёзно: чем Flow хуже дракона? Почему Flow недоработан?
1. Из-за отсутствия шампура (центральной линии алгоритма) слишком много изгибов.
2. Нет силуэта. В результате схемы растут слишком далеко вниз. А в силуэте одна ветка на экране помещается.
3. Сам геймплей редактора муторный: трудно перекидывать ветки, копировать-вставлять и так далее.
Но несмотря на эти мелочи народу нравится Flow.
Но иногда уходить вправо заставляет топология схемы — иначе не сложишь. Тогда да, читатель ожидает проблем, а там всё хорошо. Правило тогда мешает.
Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.
А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?
«Пожалуйста, ссылку на конкретное исследование.»
Ищите сами. Автор статьи даёт знания. Нужны вам эти знания или нет — это ваше личное решение.
С другой стороны, ассимметрия довольно часто бывает.
А вот с формальным обоснованием «лёгкости» всё в порядке. В основе ДРАКОНа лежат объективные правила эргономики. «Объективные» — значит не важно, нравятся они вам лично или нет, знаете вы о них или нет. Работают и всё. О них можно прочитать, всё гуглится. Примеры: запрет на пересечение линий, только прямоугольные двумерные графы, требования по выравниванию ширины и расстояний, предсказуемость (следующий элемент — внизу), единообразие (ветвление только вправо), правило «общая судьба», правило «чем правее, тем хуже», чёткое выделение циклов и прочее.
Кстати, вместо стрелок в ДРАКОНе прямые чистые линии. Стрелка в ДРАКОНе — это знак цикла.
Правило «чем правее, тем хуже» позволяет выделять неприятные сценарии (например, обрабоку ошибок).
Позволяет, но не заставляет. Если сценарии равноправны, правило не применяем.
Потому что те, кто не может читать код, дают деньги на разработку.
«почему бы в таком случае не обойтись русским языком, без блок-схем?»
Просто русский (или английский) не потянет — слишком сложный сейчас софт. Текст приходится структурировать в виде юз-кейсов. Но с юз-кейсами возникает проблема — повторы. И тогда видишь: да, надо было брать ДРАКОН с самого начала.
Эти правила не случайны. Они составлены так, чтобы выжать максимум из графического представления алгоритмов. Что дают эти правила?
1. Легкость восприятия (примеры: запрет на пересечение линий, только прямоугольные манхеттен-графы).
2. Единообразие и предсказуемость (примеры: следующий всегда внизу, ветвление всегда идёт вправо).
1. Бизнес-процессы (жизнеритмы). В отличие от должностных инструкций, диаграмм BPMN и прочего, ДРАКОН отвечает исполнителю на вопрос: Что конкретно мне делать сейчас?
2. ТЗ. ДРАКОН объясняет, как работает эта хрень.
Есть иконы "Ввод" и "Вывод". Применются для обозначения приёма и посылки сообщений.
Есть икона "Полка". Там в верхней части обычно пишут исполнителя (если их несколько). Но можно написать отправителя и получателя сигнала. Например: Браузер > Сервер приложения
См. набор икон в https://ru.wikipedia.org/wiki/ДРАКОН
Но это ДРАКОН, язык. DRAKON Editor (софт) не поддерживает на данный момент некоторые фичи языка ДРАКОН. Поэтому я прибегаю к ДРАКОНовским конечным автоматам для такого.
Это в следующей статье.