Comments 18
Задраконил блин!
Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность
И? Почему вы так не реагируете на зарубежные, чаще еще более смешные, сокращения в мире IT (софт / алгоритмы и прочее)? На те же акронимы? Переведите их на русский, они тоже прозвучат как минимум забавно. Я не «поцреот», просто фейсплам действительно неуместен. А вот относительно контента можно и пофейспалмить.
Аббревиатуру вымучили явно))
Эх, пример бы увидеть, так сказать, понятное краткое введение. А то список литературы это хорошо, а какая польза от этой штуки — непонятно.
Польза в том, что упрощается процесс алгоритмизации + радикально снижается количество ошибок.
Там в списке есть статья, как парень микроконтроллеры программировал. К ней несколько видеороликов прилагается по среде ИС Дракон (говорят что Drakon Editor попроще будет).
На ДРАКОНе удобно зависывать любую деятельность поддающуюся или нуждающуюся в алгоритмизации. А некоторые программируют на обычных языках в ДРАКОН-средах. Среды, конечно, ещё сыроваты, но разработчики прислушиваются к мнениям и довольно шустро работают.
Там в списке есть статья, как парень микроконтроллеры программировал. К ней несколько видеороликов прилагается по среде ИС Дракон (говорят что Drakon Editor попроще будет).
На ДРАКОНе удобно зависывать любую деятельность поддающуюся или нуждающуюся в алгоритмизации. А некоторые программируют на обычных языках в ДРАКОН-средах. Среды, конечно, ещё сыроваты, но разработчики прислушиваются к мнениям и довольно шустро работают.
В общем то это основной мотив на форуме forum.oberoncore.ru — там уже больше года просят убрать Дракон с форума на отдельный сайт, чтобы форум был для того, для чего изначально предназначался — для обсуждения Оберона (точнее в основном Компонентного Паскаля, а еще точнее — BlackBox Component Builder).
Тут дело в том, что во-первых драконоиды много более активные чем обероновцы, соответственно бОльшую часть постов теперь на этом форуме про дракон, а не оберон. А во-вторых, посты у них большие, пространные и малосодержательные. Читать такое частенько сложновато.
Тут дело в том, что во-первых драконоиды много более активные чем обероновцы, соответственно бОльшую часть постов теперь на этом форуме про дракон, а не оберон. А во-вторых, посты у них большие, пространные и малосодержательные. Читать такое частенько сложновато.
Многие, кто связаны с телекомом думаю вспомнили язык SDL ru.wikipedia.org/wiki/Specification_and_Description_Language
И такой тул как Tau SDL www.interface.ru/home.asp?artId=18802
И такой тул как Tau SDL www.interface.ru/home.asp?artId=18802
Одна из первых рецензий на книгу Паронджанова. Почти десятилетней давности.
Тогда я очень радовался, что, наконец, нашёлся у нас человек, который исследует вопросы когнитивной эргономики. Потому что эти вопросы не решены до сих пор, а надо было — ещё в том веке…
К сожалению, с тех пор исследования не продвинулись ни на миллиметр.
Продолжается агрессивный пиар самого слабого и спорного из описанного в книге: языка ДРАКОН.
Моё мнение таково. Сегодня визуальные языки давно привычны и широко употребляются в разных областях программирования.
Предложенная технология может привнести что-то новое только при условии радикального пересмотра и дополнительных исследований не только по эргономике визуальных представлений, но и по когнитивным технологиям в целом.
Но проблематика интересная, и заниматься ею необходимо.
Тогда я очень радовался, что, наконец, нашёлся у нас человек, который исследует вопросы когнитивной эргономики. Потому что эти вопросы не решены до сих пор, а надо было — ещё в том веке…
К сожалению, с тех пор исследования не продвинулись ни на миллиметр.
Продолжается агрессивный пиар самого слабого и спорного из описанного в книге: языка ДРАКОН.
Моё мнение таково. Сегодня визуальные языки давно привычны и широко употребляются в разных областях программирования.
Предложенная технология может привнести что-то новое только при условии радикального пересмотра и дополнительных исследований не только по эргономике визуальных представлений, но и по когнитивным технологиям в целом.
Но проблематика интересная, и заниматься ею необходимо.
Оооооочень проблематично это использовать для реальной разработки:
1. Как это хранить в версионнике? Как должны выглядеть диффы?
2. Как осуществлять полноценную навигацию и поиск в том числе по кускам кода? А если его РЕАЛЬНО много?
3. Блок-схемы сильно менее наглядны, чем код, вроде давно уже всем понятно.
4. Набирать текст тупо быстрее и удобнее, чем рисовать.
5. Конечные автоматы — далеко не единственная парадигма программирования. Насколько удобно в этой парадигме использовать, например, функции высших порядков? Вообще stateless-код?
Ну и не забываем про Windows Workflow Foundation и еще множество workflow-движков, где реализовано полностью то же самое, только применимое в реальной жизни.
Идея устарела лет на… В том виде, в котором здесь показана — полнейшая профанация и фейспалм.
1. Как это хранить в версионнике? Как должны выглядеть диффы?
2. Как осуществлять полноценную навигацию и поиск в том числе по кускам кода? А если его РЕАЛЬНО много?
3. Блок-схемы сильно менее наглядны, чем код, вроде давно уже всем понятно.
4. Набирать текст тупо быстрее и удобнее, чем рисовать.
5. Конечные автоматы — далеко не единственная парадигма программирования. Насколько удобно в этой парадигме использовать, например, функции высших порядков? Вообще stateless-код?
Ну и не забываем про Windows Workflow Foundation и еще множество workflow-движков, где реализовано полностью то же самое, только применимое в реальной жизни.
Идея устарела лет на… В том виде, в котором здесь показана — полнейшая профанация и фейспалм.
Тут нужно чётко разделять критику концепции и реализации. Что вы критикуете?
Предположу что концепцию и исходя из этого буду отвечать.
1) Diff — это текстовый инструмент. Возможно для дракона нужны будут новые типы дифов, графические.
Лично я не вижу проблем и с текстовыми дифами: например, в конечном итоге ДРАКОН-Си преобразуется в программу на Си. А сам ДРАКОН-файл можно делать в XML-формате.
2) Соответственно и проблемы поиска нет. Это реализуется в рамках среды.
3) Дракон != обычные блок-схемы. У человека очень значительная часть коры оптимизирована для обработки графики. Текст в большинстве случаев воспринимается хуже блок-схем. Если бы законы составлялись блок-схемами, то тысячам юристам пришлось бы искать другую работу.
4) Главная фишка не в скорости написания, а в скорости понимания + минимизации ошибок в конечном продукте. Дракон в ракетно-космической отрасли был создан. Фишка Дракона — учёт правил эргономики. Блок-схемы на драконе получаются более понятные, чем обычные. P.S. У меня рисовать получается быстрее.
5) Есть гибридный язык ДРАКОН-Erlang. Поддерживается в Drakon Editor.
Похожее, да не то. Буду благодарен ссылкам на другие движки кроме WWF.
Предположу что концепцию и исходя из этого буду отвечать.
1) Diff — это текстовый инструмент. Возможно для дракона нужны будут новые типы дифов, графические.
Лично я не вижу проблем и с текстовыми дифами: например, в конечном итоге ДРАКОН-Си преобразуется в программу на Си. А сам ДРАКОН-файл можно делать в XML-формате.
2) Соответственно и проблемы поиска нет. Это реализуется в рамках среды.
3) Дракон != обычные блок-схемы. У человека очень значительная часть коры оптимизирована для обработки графики. Текст в большинстве случаев воспринимается хуже блок-схем. Если бы законы составлялись блок-схемами, то тысячам юристам пришлось бы искать другую работу.
4) Главная фишка не в скорости написания, а в скорости понимания + минимизации ошибок в конечном продукте. Дракон в ракетно-космической отрасли был создан. Фишка Дракона — учёт правил эргономики. Блок-схемы на драконе получаются более понятные, чем обычные. P.S. У меня рисовать получается быстрее.
5) Есть гибридный язык ДРАКОН-Erlang. Поддерживается в Drakon Editor.
множество workflow-движков, где реализовано полностью то же самое
Похожее, да не то. Буду благодарен ссылкам на другие движки кроме WWF.
Я критикую концепцию.
1. Ок. Предложите вариант графического диффа.
2. Не вижу как.
3. А книги бы умерли и остались бы только комиксы. Про понятность блок-схем тоже писали уже все кому не лень.
4. Вот я с трудом их понимаю. Потому что они большие и запутанные. А если резать на мелкие «процедуры» — влетаем в проблему навигации. Вы понимаете что цикломатическая сложность управляющих алгоритмов ракеты и современной бизнес-логики — очень разные вещи?
5. Чуть позже, с телефона пишу.
1. Ок. Предложите вариант графического диффа.
2. Не вижу как.
3. А книги бы умерли и остались бы только комиксы. Про понятность блок-схем тоже писали уже все кому не лень.
4. Вот я с трудом их понимаю. Потому что они большие и запутанные. А если резать на мелкие «процедуры» — влетаем в проблему навигации. Вы понимаете что цикломатическая сложность управляющих алгоритмов ракеты и современной бизнес-логики — очень разные вещи?
5. Чуть позже, с телефона пишу.
1) Самый простой способ показывать исчезнувшие блоки одним цветом, а появившиеся другим. Если изменилось только содержание блока, то можно внутри обойтись традиционными плюсами и минусами
Вообще diff, как средство понимания изменений, годится только для небольших изменений. Если изменения глобальны, то мы имеем труднопонимаемую кашу.
Если diff вас интересует как инструмент создания патчей, то текстовые версии обычного diff могут применимы к программам и ДРАКОН-программам
2) Ctrl-F, вводим слово. Далее среда выделяет один блок, потом другой и т.п.
3) Комиксами трудно нарисовать законы. Комикс — очень трудоёмкий жанр.
Наверное, писали про понятность обычных блок-схем. ДРАКОН — это не обычные блок-схемы. Вот краткое введение.
4) Опять речь идёт об обычных блок-схемах, которые != ДРАКОН-схемам. Ракеты не разрабатывал, но думаю сложность там очень высокая. В одном БУРАНе было около 80 внутренних управляющих систем.
5) Возможно, если в эти продукты ввести поддержку ДРАКОНа, их эффективность повысится.
Вообще diff, как средство понимания изменений, годится только для небольших изменений. Если изменения глобальны, то мы имеем труднопонимаемую кашу.
Если diff вас интересует как инструмент создания патчей, то текстовые версии обычного diff могут применимы к программам и ДРАКОН-программам
2) Ctrl-F, вводим слово. Далее среда выделяет один блок, потом другой и т.п.
3) Комиксами трудно нарисовать законы. Комикс — очень трудоёмкий жанр.
Наверное, писали про понятность обычных блок-схем. ДРАКОН — это не обычные блок-схемы. Вот краткое введение.
4) Опять речь идёт об обычных блок-схемах, которые != ДРАКОН-схемам. Ракеты не разрабатывал, но думаю сложность там очень высокая. В одном БУРАНе было около 80 внутренних управляющих систем.
5) Возможно, если в эти продукты ввести поддержку ДРАКОНа, их эффективность повысится.
Мне не нравится название, но нравятся три идеи в языке Дракон:
1. Деление алгоритма на ветки;
2. Правило «чем правее, тем хуже»;
3. Правило «шампура»: основная ветвь процесса должна идти по строгой вертикали.
Это очень хорошие идеи. Опишу опыт применения в реальных проектах.
1. Деление алгоритма на ветки;
2. Правило «чем правее, тем хуже»;
3. Правило «шампура»: основная ветвь процесса должна идти по строгой вертикали.
Это очень хорошие идеи. Опишу опыт применения в реальных проектах.
Sign up to leave a comment.
Визуальный язык ДРАКОН и его применение в ракетно-космической отрасли, медицине и других областях. Видео доклада В. Паронджанова