«Зачем применять для 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. ТЗ. ДРАКОН объясняет, как работает эта хрень.
На местах люди работают без действующей, живой документации. Может, где-то и написаны какие-то инструкции, но их не читает никто. Каша бизнеса бурлит и варится неформально. Всё держится на личных связях и личных качествах конкретных людей. Царит беспорядок, и при этом бизнес зарабатывает деньги!
А иногда не зарабатывает. И тогда начальники и консультанты начинают напряжённо рисовать BPMN-схемы бизнес-процессов. Смотрел я на эти художества, и вдруг понял, в чём принципиальное отличие BPMN от ДРАКОНа.
BPMN-схемы ориентированы на общее изображение процессов. Они дают высокому начальству иллюзию контроля. Это психологически приятно, но делу не помогает.
ДРАКОН, в свою очередь, говорит конкретному сотруднику что надо сделать прямо сейчас.
BPMN доставляет приятные ощущения начальнику, а ДРАКОН помогает исполнителю делать свою работу хорошо.
С просьбой сделать оффлайн-редактор ко мне обращались уже несколько трудящихся. Надо будет сделать десктоп-версию редактора. Но главное — версию для планшетов.
Оказалось, что тач-скрин вместе с ДРАКОНом даёт новое качество. Споры, что лучше — клавиатура или мышь — устарели. Тач-скрин сильно их опережает по удобству работы. Однако, превосходство тач-скрина возникает, только если редактор под это специально оптимизирован. Например, перетаскивание объектов, эффективное с мышкой, на тач-скрине неудобно. Надо, чтобы человек только тыкал пальцем, и всё само рисовалось. Кто не верит, может попробовать drakon.tech на айпаде.
Когда уже наконец сделают нормальный инструментарий под ДРАКОН на современных технологиях? Это вопрос к молодым и энергичным программистам. Золотая тема для стартапа. Всё уже придумано и опробовано, бери и делай.
Речь идёт о дракон-схемах типа «силуэт». Силуэт — гениальное изобретение.
Обычно большой алгоритм разбивают на несколько маленьких функций. Это называется «декомпозиция». Цена декомпозиции такая: между функциями в процессе разработки приходися прыгать, а кроме того, вызовы функций приходится связывать аргументами и возвращаемыми значениями.
А вот силуэт совмещает приятное с полезным.
С одной стороны, большой алгоритм разбивается на несколько малых.
С другой — силуэт устраняет ненужное связывание и скакание по коду.
Я целиком за декомпозицию. Но часто она слишком дорого стоит, и тогда выручает силуэт.
Чтобы потом понимать написанный код. Но этот вопрос не относится к языку ДРАКОН. Как хотите, так и пишите. Другое дело, что текущие реализации ДРАКОНа не позволяют нарисовать алгоритм в алгоритме. Это да. Поэтому в замыканиях только текст, а не графические примитивы.
«замыкание вам придётся иммитировать глобальными переменными»
Не придётся. Замыкания работают, как обычно.
Если требуется нестандартная лямбда, выносите алгоритм в отдельную функцию и вызывайте эту функцию в лямбде.
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. ТЗ. ДРАКОН объясняет, как работает эта хрень.
А иногда не зарабатывает. И тогда начальники и консультанты начинают напряжённо рисовать BPMN-схемы бизнес-процессов. Смотрел я на эти художества, и вдруг понял, в чём принципиальное отличие BPMN от ДРАКОНа.
BPMN-схемы ориентированы на общее изображение процессов. Они дают высокому начальству иллюзию контроля. Это психологически приятно, но делу не помогает.
ДРАКОН, в свою очередь, говорит конкретному сотруднику что надо сделать прямо сейчас.
BPMN доставляет приятные ощущения начальнику, а ДРАКОН помогает исполнителю делать свою работу хорошо.
Оказалось, что тач-скрин вместе с ДРАКОНом даёт новое качество. Споры, что лучше — клавиатура или мышь — устарели. Тач-скрин сильно их опережает по удобству работы. Однако, превосходство тач-скрина возникает, только если редактор под это специально оптимизирован. Например, перетаскивание объектов, эффективное с мышкой, на тач-скрине неудобно. Надо, чтобы человек только тыкал пальцем, и всё само рисовалось. Кто не верит, может попробовать drakon.tech на айпаде.
Когда уже наконец сделают нормальный инструментарий под ДРАКОН на современных технологиях? Это вопрос к молодым и энергичным программистам. Золотая тема для стартапа. Всё уже придумано и опробовано, бери и делай.
Обычно большой алгоритм разбивают на несколько маленьких функций. Это называется «декомпозиция». Цена декомпозиции такая: между функциями в процессе разработки приходися прыгать, а кроме того, вызовы функций приходится связывать аргументами и возвращаемыми значениями.
А вот силуэт совмещает приятное с полезным.
С одной стороны, большой алгоритм разбивается на несколько малых.
С другой — силуэт устраняет ненужное связывание и скакание по коду.
Я целиком за декомпозицию. Но часто она слишком дорого стоит, и тогда выручает силуэт.