Comments 86
А где ответ на вопрос в заголовке? Это Хабр или Твиттер?
1 Ответ: нет.
1) ВПК и НИУ МО используют ГОСТ 15.203 при выполнении НИОКР
2) ДОГОЗ и причастные к ГПВ предприятия, в основном, Ростеха не заинтересованы изменить порядок создания макулатуры в течение нескольких лет, общения в несколько итераций с ВП на предмет расстановки запятых и дутых перечней каталогизации, КИМП, импортозамещения и тп, а далее наклеивания шильдиков на китайское барахло
2 Чтобы изменить ситуацию (не в ВПК), необходимо привлекать иностранных (или около иностранных) производителей ПО (например, JB) с соответствующими бюджетами на продакт, коммьюнити и т.п.
3 Вопрос к акторам п. 2. Оно им нужно? А пользователю приложения в смартфоне?
Брыксин Тимофей Александрович
Платформа для создания специализированных визуальных сред разработки программного обеспечения
Специальность 05.13.11 —
Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей
Спасибо за критику. Я учел ваше замечание и полностью переписал текст статьи.
В общем, идея Дракона опоздала на много-много лет.
идея Дракона опоздала на много-много лет.
Это не так. Вот пример. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Подробности по ссылке youtu.be/_XOuhV_8N_I
Что касается запоздалости Дракона – то, раз уж я начал говорить про VCS, то продолжу:
Современные подходы и средства разработки предполагают активное использование систем контроля версий (тот же git). Branch/merge (ну или rebase) – обязательная процедура, без этого мы остаёмся на уровне небольших проектов XX века.
Так что чтобы имело смысл говорить о какой-то современности Дракона – его надо подтянуть хотя бы по этому критерию (на самом деле не только по этому).
это не довод. Единичный проект можно создать хоть в машинных кодах.
Это вовсе не единичный проект (хотя и не массовый). Это один из проектов Алексея Муравицкого — системного интегратора фирмы Овен.
Насчет контроля версий вы правы. Этот недостаток надо устранять
Во всех случаях графика ДРАКОНа остается неизменной. А внутри графических фигур пишут код согласно правилам выбранного языка программировния: С, Java, C#, Python, Javascript, Tcl, Erlang и т.д.
0
Преимущества ДРАКОНа таковы:
— графика ДРАКОНа строится методом визуального логического вывода из двух визуальных аксиом: аксиомы-примитив и аксиомы-силуэт. Это означает, что графика является почти безошибочной.
— Язык ДРАКОН опирается на идеи когнитивной эргономики. То есть идея алгоритма соединяетс с идеей когнитивной эргономики. Алгоритмы становятся эргономичными (people-friendly). Это дает повышенную ясность и удобство в работе и так; е работает на минимизацию числа ошибок.
0
Переведу с наукообразного языка на человеческий:
Условный оператор компактней.
Если следовать принятым в Драконе правилам — схема получается более читаемая. Например, ветвление происходит только вниз и вправо. Причём вниз ведёт та ветвь, которая по смыслу соответствует "всё хорошо", а вправо — "что-то не так, нужна другая обработка".
У диаграммы деятельности более широкое применение. Ей можно описывать параллельные процессы и их взаимодействие. Круглишки, в которые сходятся стрелки, имеют возможность размещать иконки AND, OR, XOR.
На мой взгляд это всё вкусовщина. Сам последнее время использую то, что дают в markdown. Если нужно нарисовать бизнес-процесс, то мне больше нравится стандарт BPMN 2.0.
Замечу также, что в предлагаемом стандарте Дракон есть прикольные идеи (например отсылка к вероятностям срабатывания или "нормальности" в условных переходах), но они неочевидны после прочтения 70 страничного вложения. Стоило, на мой взгляд, в этой статье перечислить фичи и как ими пользоваться.
У диаграммы деятельности более широкое применение. Ей можно описывать параллельные процессы и их взаимодействие. Круглишки, в которые сходятся стрелки, имеют возможность размещать иконки AND, OR, XOR.
Отвечу на тезис про «размещать иконки AND, OR, XOR».
В языке ДРАКОН вопрос решен иначе — без знаков логических связок (так как они являются источниками ошибок).
Использован принцип «конъюнкция без знака конъюнкции»,
«дизъюнкция без знака дизъюнкции».
Посмотрите книгу «Паронджанов В.Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М., 2019. — 374 с. — Иллюстраций: 195».
drakon.su/_media/24_zhizneritm20.pdf
Часть 3. Алгоритмическая логика. Математическая логика в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
В ДРАКОНЕ есть ряд соглашений, которые позволяют меньше рисовать. И есть правила оформления ветвлений, делающие их более наглядными. Да и, пожалуй, всё.
Вообще, выразительность у Дракона очень слабая. На нём можно описывать только простые алгоритмы, которые сейчас встречаются в виде тела процедуры.
Писать на нём целый большой проект — это совмещение неприятного с бесполезным. А вот формализовать какую-то последовательность действий — мило дело.
Цикл с итератором — упал отжался 30 раз
Условный оператор — налево, направо марш
Любят военные все свое )))
Всё нормально. Дракон как стандарт блок-схем — штука довольно неплохая.
А алгоритмы в виде блок схем часто нужны бывают людям, далёким от ИТ. Причём алгоритм для людей, а не для компьютеров.
Я читал, что на некоторых предприятиях обнаружили, что работники понимают последовательность действий, которую от них хотят, в виде блок-схемы лучше, чем в виде голого текста.
Я посмотрел на язык, и мне кажется, у него есть определённого рода проблемы с поддержкой некоторых типовых конструкций современных языков программирования.
Например, допустим, у меня есть такая имплементация методов для какой-то структуры:
impl <F> Mytrait<T=F> for MyStruct<F,F,i32> where F: Fn(i32)->i32И как мне эти ограничения задать в виде блок-схем? А ведь это критически важно для описания того, что этот код делает, а что нет.
Пример: типы данных и названия для аргументов функции, тип возвращаемого значения и прочее пишем обычным текстом в иконе «Формальные параметры». Тело функции задаём в виде графических конструкций ДРАКОНа.
Пример содержания иконы «Формальные параметры» в DRAKON Editor:
public virtual // атрибуты функции
std::string const & param1 // аргумент 1
float param2 // аргумент 2
returns std::string // тип возвращаемого значения
Вы не можете описывать алгоритмы без описания типов данных, потому что в этом случае вы используете произвольный набор свойств (в философском смысле). Например, если у вас в блок-схеме написано "следующее число" а следующего числа не существует (потому что это int с ограниченной битностью, или float с NaN у которого нет порядка), то что должно случиться?
Кстати, совет от представителя индустрии. Перестаньте писать капсом название, оно напоминает то ли отрыжку КОБОЛа, то ли нелепую аббревиатуру.
Причем в тексте статьи вспоминается недавний случай в Боингами, где к основному алгоритму управления вопросов не было, рисуй его хоть в виде какой угодно блок-схемы, была проблема в отказавших датчикам и настройках системы «по умолчанию».
В то же время в самом первом примере по проращиванию рассады помидоров на ДРАКОНЕ совершенно очевидно не отслеживаются (вполне возможные) аварийные (нештатные) ситуации, которые должны были бы контролироваться таймерами, но этого не сделано.
Ну и в чем тогда преимущество — хоть на ЯП не опишите реакцию системы на недопустимые сигналы, хоть на блок-схемах — лучше не станет.
В Драконе есть очень вредная концепция: указание в конце ветки, какая ветка должна выполняться следующей. Самый настоящий GOTO, причём там, где лучше было бы обойтись без него. Нужны какие-то более адекватные правила управления порядком выполнения веток.
Вообще говоря, у ветки нет однозначного отображения в языках программирования. Это либо процедура, определённая внутри другой процедуры, либо просто кусок кода, который не поместился по высоте на листе чертежа.
В первом случае в конце ветки должен быть RETURN к месту вызова, а не метка другой ветки.
Во втором случае лучше бы было ветку вообще не выделять.
Обычно большой алгоритм разбивают на несколько маленьких функций. Это называется «декомпозиция». Цена декомпозиции такая: между функциями в процессе разработки приходися прыгать, а кроме того, вызовы функций приходится связывать аргументами и возвращаемыми значениями.
А вот силуэт совмещает приятное с полезным.
С одной стороны, большой алгоритм разбивается на несколько малых.
С другой — силуэт устраняет ненужное связывание и скакание по коду.
Я целиком за декомпозицию. Но часто она слишком дорого стоит, и тогда выручает силуэт.
В Драконе есть очень вредная концепция: указание в конце ветки, какая ветка должна выполняться следующей. Самый настоящий GOTO, причём там, где лучше было бы обойтись без него. Нужны какие-то более адекватные правила управления порядком выполнения веток
В ДРАКОНе нет оператора goto и никогда не было.
Глядя на дракон-схему, вы не увидите goto даже под микроскопом.
«Самый настоящий goto», о котором вы пишете, формируется автоматически (а не пишется вручную). А это совсем другое дело.
На уровне машинных команд вы найдете много команд перехода, так как любой цикл и любое ветвление на уровне машинных команд реализуются командой перехода jump или ее аналогами.
В Драконе есть очень вредная концепция: указание в конце ветки, какая ветка должна выполняться следующей… Нужны какие-то более адекватные правила управления порядком выполнения веток
Ничего вредного здесь нет.
Это недоразумение. Ветка бывает не только одноадресной (как вы предполагаете), но и многоадресной, то есть имеющей две и больше икон Адрес.
Глядя на дракон-схему, вы не увидите goto даже под микроскопом.
А вот не врите.
Вот они. Безусловные переходы к другим веткам.
Ветка бывает не только одноадресной (как вы предполагаете), но и многоадресной, то есть имеющей две и больше икон Адрес.
Т.е. несколько точек выхода из ветки. Что ж в этом хорошего? Единственный случай, когда это может быть полезно, а не вредно — описание конечного автомата. Но вряд ли кому-то придёт в голову представлять конечный автомат в виде дракон-схемы.
Помогаю вам читать — там написано «Приручение попугаев», «Учимся говорить». Где вы видите goto? Нигде не написано goto!
Похоже, что у вас плохо со зрением. Вы видите то, чего на схеме нет.
Ваш рисунок подтвердает, что на дракон-схеме нет оператора goto.
Единственный случай, когда это может быть полезно, а не вредно — описание конечного автомата. Но вряд ли кому-то придёт в голову представлять конечный автомат в виде дракон-схемы.
Дракон-схема силуэт — это и есть конечный автомат.
Рекомендую вам прочитать статью «Митькин С.Б. Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019» drakonhub.com/files/pe_drakon_automata_mitkin_2019.pdf
Помогаю вам читать — там написано «Приручение попугаев», «Учимся говорить». Где вы видите goto? Нигде не написано goto!
Как-то раз один человек назвал меня слепым, когда на часах было 14:00, а я сказал "два часа".
Очень похожая ситуация.
Дракон-схема силуэт — это и есть конечный автомат.
Это полностью меняет дело. Признаю, использовать икону "адрес" таким образом — полезно. Жаль, что в обзорных статья по языку об этом не пишут.
«Митькин С.Б. Автоматное программирование на языке ДРАКОН
А вот это уже интересно. С удовольствием почитаю.
Дракон-схема силуэт — это и есть конечный автомат
Уточню. Пользователь языка ДРАКОН может по своему усмотрению трактовать дракон-схему силуэт
— либо как конечный автомат,
— либо нет (то есть как обычный процедурный подход).
Например, в инструментальной программе «ИС Дракон» Геннадия Тышова предусмотрены три режима работы:
— Автомат 1;
— Автомат 2;
— Процедурное программирование.
Автором режимов «Автомат 1» и «Автомат 2» является Сергей Дмитриевич Ефанов (Липецк).
Если силуэт трактовать как обычный процедурный подход, то икону "адрес" нужно трактовать как комбинацию вызова процедуры с оптимизацией хвостовой рекурсии и выхода из процедуры.
Я описал строгие требования к ДРАКОН-конструктору. Сегодня имеются три ДРАКОН конструктора Геннадия Тышова и Степана Митькина (2 шт.). Это их дело, как трактовать ветку.
Для меня важно, чтобы выполнялись мои требования к ДРАКОН-конструктору. Все остальное автор программы ДРАКОН-конструктор определяет по своему усмотрению.
Зенитчик, если вы захотите разработать свой ДРАКОН-конструктор, вы вправе трактовать ветку по своему усмотрению (но с учетом моих требований).
Как язык программирования Дракон неудобен. Дело в том, что обычному человеку писать легче, чем рисовать. А следовательно, разработка в текстовом режиме — удобнее, чем в графическом.
Дракон мог бы быть хорош в качестве графического представления алгоритмов (при условии автоматического преобразования кода в графику), но, судя по этой статье, разработчики Дракона не имеют опыта разработки на современных языках программирования и не знакомы и не знакомы с современными подходами к разработке, а потому создают что-то далёкое от практики.
Другое дело — читать код. Здесь ДРАКОНу нет равных, потому что можно пальчиком отследить ход выполнения программы. Не нужно по фигурным скобкам скакать.
Дело в том, что обычному человеку писать легче, чем рисовать.
А вот сие совсем не является строгой истиной. Нарисовать два условно-прямоугольных пятна "А" и "Б" и между ними стрелку может практически любой. Прочитать такое — тоже. И это даже куда легче, чем текстом.
Трудно рисовать красиво, это факт. А вот схемки-майндмепы-каракули доступны всем(кто имеет физическую возможность). Те же майнмепы хорошо соответствуют тому, как работает человеческое мышление — и при этом плохо переносятся в текст из-за развитой древовидности и возможных связей между разными ветвями. Зато в виде наброска руками — легко.
В качестве одного из примеров назову онлайн программу DrakonHub Степана Митькина drakonhub.com
Хорошо, изменю формулировку: печатать на клавиатуре легче, чем рисовать мышью, и даже чем размещать прямоугольники мышью.
А оффлайн версии нет? Не люблю, когда сайт вместо приложения.
Оказалось, что тач-скрин вместе с ДРАКОНом даёт новое качество. Споры, что лучше — клавиатура или мышь — устарели. Тач-скрин сильно их опережает по удобству работы. Однако, превосходство тач-скрина возникает, только если редактор под это специально оптимизирован. Например, перетаскивание объектов, эффективное с мышкой, на тач-скрине неудобно. Надо, чтобы человек только тыкал пальцем, и всё само рисовалось. Кто не верит, может попробовать drakon.tech на айпаде.
Когда уже наконец сделают нормальный инструментарий под ДРАКОН на современных технологиях? Это вопрос к молодым и энергичным программистам. Золотая тема для стартапа. Всё уже придумано и опробовано, бери и делай.
Споры, что лучше — клавиатура или мышь — устарели.
Разумеется. Потому что у нормальной программы должны быть оба варианта управления.
Тач-скрин сильно их опережает по удобству работы. Однако, превосходство тач-скрина возникает, только если редактор под это специально оптимизирован.
Взаимоисключающие параметры. Если редактор "специально оптимизирован" — то превосходство будет у того устройства ввода, под которое он оптимизирован.
Кстати, о тач паде. Вы пользуетесь планшетными компьюетрами? Как Вам удалось привыкнуть работать без горячих клавиш? Ну, банально, выделение кнопкой Shift+стрелки, переходы в начало и в конец — home и end, сдвиг на слово Crtl+стрелки ?
Вообще, работая в ритейле, испытываю смешанные чувства по поводу спора о стрелочках. Для меня радость, если в компании есть документация, а в ней есть статья на нужную тему, а в ней есть фотография доски с хоть каким-то объяснением происходящего, пусть даже это объяснение нарисовано поверх прежней схемы.
А иногда не зарабатывает. И тогда начальники и консультанты начинают напряжённо рисовать BPMN-схемы бизнес-процессов. Смотрел я на эти художества, и вдруг понял, в чём принципиальное отличие BPMN от ДРАКОНа.
BPMN-схемы ориентированы на общее изображение процессов. Они дают высокому начальству иллюзию контроля. Это психологически приятно, но делу не помогает.
ДРАКОН, в свою очередь, говорит конкретному сотруднику что надо сделать прямо сейчас.
BPMN доставляет приятные ощущения начальнику, а ДРАКОН помогает исполнителю делать свою работу хорошо.
BPMN-схемы ориентированы ...
У Дракон-а и BPMN действительно разные сферы применения. Дракон, если я правильно понял, ориентирован на создание небольших отказоустойчивых алгоритмов. Если алгоритм будет большим, то вряд ли сыграют визуальные преимущества, для проверки моих слов — откройте любую программу в IDA Pro.
… но делу не помогает
Не могу согласиться. Ещё как помогает. BPMN ориентирован на описание бизнес-процессов. Для решения задач автоматизации, при первоначальном отсутствии этих схем, они зачастую рисуются со слов сотрудников на местах. Для обработки таких схем используется разнообразное ПО, например ARIS. Если схемы уже есть — это хорошо. Это хорошо, даже если они нарисованы не по стандарту. Общие схемы хорошо дополняют самодокументируемый код. Их задача для разработчика — дать контекст.
Они дают высокому начальству иллюзию контроля
Вы думаете топы их куда-то в папку складывают и радуются? Это вообще не так работает. BPMN-схемы используются для проработки какого-то проекта. Иногда и топы могут заинтересоваться какой-то деталью и потыкать пальцем в схему, позадавать вопросы (например спросить что-то такое: мы это везём отсюда сюда, а вот этот ждёт, а потом сюда, мы можем это сразу везти сюда?). Никогда не встречал ситуации, когда от стандарта BPMN требовалось бы что-то большее, чем то, что в нём уже есть.
Вы правы, когда говорите, что язык ДРАКОН обеспечивает «создание отказоустойчивых алгоритмов».
Но вы не правы, когда говорите, что язык ДРАКОН предназначен для «создания небольших алгоритмов».
Как раз наоборот. Чем больше и сложнее алгоритм, тем больше выигрыш от использования языка ДРАКОН.
Из предложенного описания стандарта это неочевидно.
Можете показать на примере?
Посмотрите главу 2 стр. 22—50 и еще стр. 53, 54 в книге:
Паронджанов В.Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М., 2019. — 374 с. — drakon.su/_media/24_zhizneritm20.pdf
Оглавление без номеров страниц — это такой дизайнерский приём?
Звучит как "дура, зато красивая".
Ваше замечание учтено.
В книгу добавлено работающее (по закладкам) краткое содержание — см. страницы 3, 4.
drakon.su/_media/24_zhizneritm20.pdf
Отвечаю по порядку.
1. Технология разработки сложных систем на основе графического языка, предшественника Дракона, была успешно применена в СССР задолго до появления UML. Бортовая система Бурана была сделана именно с помощью прототипа Дракона. Она оказалась не просто успешной, а феноменально успешной. Единственный полет в автоматическом режиме с посадкой в сложнейших погодных условиях – подобного в мире не делал никто и никогда. И это получилось, так как алгоритмы рисовали инженеры, а кодировали потом программисты по этим схемам. И получилось благодаря формальной строгости Дракона. С помощью UML или, прости Господи, блок-схем такое сделать практически нереально. Так как их рисуют каждый по-своему.
2. Диссертация Брыксина не полна. Написать диссер, в котором есть анализ графических языков, и не упомянуть при этом Дракон – это надо умудриться. Надо было написать хотя бы несколько строк о том, какие недостатки присущи Дракону – без этого его исследование не может считаться законченным. Я не думаю, что он не знает про Дракон. Значит сознательно замалчивает. Почему?
3. Насчет писать/рисовать. Наши наблюдения показывают, что для разных людей понятие удобства создавать алгоритмы – очень разное. Замечу, что для программистов удобнее писать текст/код. Я сам программист со стажем более 45 лет, поэтому говорю от первого лица. Но оказывается, существует множество людей, которым надо алгоритмы создавать, но они НЕ являются программистами. Они – инженеры-технологи. И им гораздо удобнее создавать и читать чертежи/схемы. Я об этом сказал в докладе на конференции День Оберона – 2019 в Орле.
Вот ссылка: www.youtube.com/watch?v=nGvpO51gBRI
Эти люди создают управляющие комплексы различного рода с микропроцессорами. И им надо создавать алгоритмы для этих микропроцессоров. Они НЕ программисты ни по образованию, ни по призванию. Оказывается, для подобных разработок гораздо удобнее использовать строгий формализованный графический язык типа Дракона, а не текст/код на обычном языке программирования.
4. В Вооруженных Силах подавляющее большинство компьютерных систем – это бортовые системы. Надежность для подобных систем – абсолютное требование. Содержать вместе с основной армией еще и армию высококвалифицированных программистов – сильно накладно будет. Программированию обучать долго и получается не у всех. А делать алгоритмы на Драконе – это могут ВСЕ. Успешность такого подхода убедительно доказана Бураном.
5. Но нужна разработка промышленной IDE для разработки алгоритмов на Драконе.
IDE, естественно, должна поддерживать как создание Дракон-схем, так и их выполнение. Ибо алгоритм, как обычно, требуется отладить. И опыт применения Дракона подсказывает, что ошибок будет меньше значительно по сравнению с написанием кода программы на традиционных языках программирования.
А после отладки Дракон-схема легко может быть конвертирована либо в код на языке программирования, либо непосредственно в коды конкретного микропроцессора.
6. Мы у себя в Астраханском техническом универе силами студентов пытаемся создать среду для разработки Дракон-схем (см. доклад по ссылке выше). Два студента независимо разрабатывают две IDE с Драконом. Один уже написал простейший интерпретатор Дракон-схемы, разработав ее текстовое представление. Второй пытается создать сначала редактор. Надеюсь, года за два что-нибудь заработает. Мы хотим обучать студентов алгоритмике, используя Дракон в рамках IDE.
что для программистов удобнее писать текст/код.
Не только для программистов. По мере усложнения задачи "мышиные операции" сперва перестают быть удобными, а потом возникает потребность в точности, превышающей возможности руки, держащей мышь.
Скажем, я в чертёжных программах я уже перестал указывать точки мышью — ввожу их координаты.
Пример плохого интерфейса — таблицы в Word. Пока допустимо проводить линии "на глазок" — хорошо и удобно таскать их мышью, но когда нужно сделать документ по образцу, а там закреплённые стандартом ширины строк и столбцов, то выставление каждой линии мышью превращается в ад, а ручной ввод ширины делается через форму настроек, которую приходится открывать и закрывать.
Порой доходило до того, что я писал таблицы в HTML, и портировал их в Word.
Возможность программировать мышью — хорошо, но отсутствие возможности программировать без мыши — это фатальный недостаток, с которым язык не может жить.
Возможность программировать мышью — хорошо, но отсутствие возможности программировать без мыши — это фатальный недостаток, с которым язык не может жить.
Следует различать язык и его инструментальную программу, например ДРАКОН-конструктор.
Решить проблему графики ДРАКОНа можно с помощью быстрых клавиш. Один из разработчиков ДРАКОН-конструктора действительно решил эту проблему с помощью быстрых клавиш.
К сожалению, он не выложил свою программу в общий доступ.
Следует различать язык и его инструментальную программу, например ДРАКОН-конструктор.
Видите ли в чём дело, если бы на ДРАКОНе можно было программировать в блокноте или ещё какой-то программе, которая есть у всех, то его можно было бы рассматривать отдельно от ДРАКОН-конструктора.
Но поскольку это не так — увы, проблемы ДРАКОН-конструктора становятся проблемами ДРАКОНА.
Кстати, файлы, которые создаёт дракон-конструктор, человекочитаемые? Если я открою его блокнотом, что я увижу?
Можно ее написать в Блокноте, и выполнить.
Но нашему заказчику текст не нужен. Ему нужен именно чертеж.
Он сам умеет писать программы на бейсике, но не пишет. А делает дракон — схемы в редакторе Тышова.
Так ему удобнее и понятнее.
Поэтому ваше предпочтение текста — это ваше личное предпочтение.
Другим людям предпочтительнее видеть чертежи/схемы.
Поэтому ваше предпочтение текста — это ваше личное предпочтение.
Другим людям предпочтительнее видеть чертежи/схемы.
Вы, похоже, неправильно меня поняли. Видеть схемы я и сам не против.
Но писать предпочитаю текст, и чтобы этот текст автоматически превращался в схему.
А мы как раз и сделали текстовое представление дракон-схемы.
Можно ссылочку?
Для представления переменных использует силуэт, обозначая ветки: Входные, Выходные, Внутренние (переменные).
И все у него наглядно.
Имы в Москве были еще в паре мест, где именно схемы хотели, а не код.
Вот и занялись, преследуя и свои цели тоже.
Ибо сейчас в вуз приходят люди, которые об алгоритмизации понятия не имеют.
А учить надо. Блок-схемы все рисуют самым разным образом. Один студент рисовал вложенные IF по-арабски — справа налево… :)))))))
2. Язык и интерпретатор схемы — это пока курсовая студенческая. Там работать и работать. Поэтому в сети пока нет. Я ж написал, что года за 2 чего-нить сделаем реальное.
А учить надо. Блок-схемы все рисуют самым разным образом. Один студент рисовал
Ну, тут-то спору нет. Я полностью согласен, что ДРАКОН-схемы — это очень хороший стандарт графического представления алгоритмов.
Я ж написал, что года за 2 чего-нить сделаем реальное.
Тогда хоть ссылку на стандарт текстового представления ДРАКОН-схем дайте.
Так что на счёт текстового представления ДРАКОН-схем?
@Zenitchik Вы можете посмотреть две книги по языку ДРАКОН:
https://drakon.su/_media/23_zhizneritm22.pdf
Вопросы можно задавать на форуме https://forum.drakon.su/ или по имейлу vdp2007@bk.ru
Вообще все действия по созданию схемы алгоритмов можно делать клавиатурой. Для этого есть горячие клавиши.
Тем более, что заготовку начальную тоже можно делать сразу.
Вопрос в реализации редактора.
Проблема — в мышлении создателя алгоритмов.
Как программист могу сказать, что писать словами — это просто привычка с одной стороны, и предрасположенность с другой. Мы опрашивали студентов. Одни говорят, что писать псевдокод удобнее, другие — что рисовать схему понятнее.
Есть и такие, которым пофигу.
И опять же, мы не просто так за Дракон взялись. Есть в Москве люди, которые даже при отсутствии полноценной ИДЕ применяют Дракон (вполне успешно) именно для разработки необходимых алгоритмов.
Поэтому мои слова выше не на пустом месте сказаны, а исходя из встреч с реальными людьми.
На Хабре есть несколько статей, посвященных языку ДРАКОН.
Они, в частности, ссылаются на хаб «Ненормальное программирование».
Это некорректно. Нужно, чтобы язык ДРАКОН относился к хабу «Визуальное программирование».
Кстати говоря, версия для android есть?
На устройствах без клавиатуры, ДРАКОН был бы чертовски полезен.
Желтые кружки обозначают валентные точки.
Вы не реализовали алгоритм, а только набросали его схему. Теперь нужно вбить выражения условий и имена выполняемых команд.
Вы правы.
Обратите внимание. Пользователю запрещено проводить соединительные линии между фигурами. Линии проводит автоматичски программа ДРАКОН-конструктор.
Фишка в том, что ошибки в разветвлениях и циклах могут быть более неприятными, чем ошибки на линейных участках программы.
Язык ДРАКОН сокращает число ошибок.
Роман Озеров пишет: (https://bit.ly/2NHnYzb см. комментарии к видео)
Я на ДРАКОНе работаю уже 6 лет.
Любое создание программы начинаю с него и при отладке работаю только с ним.
Скорость разработки, качество возрастает в разы!
ДРАКОН это сила, но многие не догоняют, думают, что это обычная блок-схема...
Фишка в том, что ошибки в разветвлениях и циклах могут быть более неприятными, чем ошибки на линейных участках программы.
Ошибка в ветвлении — это почти всегда ошибка в условии. Рисование тут в подавляющем большинстве случаев ни при чём.
Ошибки в линейных участках программы — это почти всегда смысловые ошибки, а не программные. Это самое худшее, что может случиться.
Ошибка в ветвлении — это почти всегда ошибка в условии.
Вы имеете в виду ошибки в условных выражениях.
В языке ДРАКОН можно обойтись без условных выражений, используя принцип «Конъюнкция без знака конъюнкции»,
Дизъюнкция без знака дизъюнкции".
Вы имеете в виду ошибки в условных выражениях.
Да, именно их.
используя принцип «Конъюнкция без знака конъюнкции»,
Дизъюнкция без знака дизъюнкции".
А скомпилируется это потом в выражения?
А скомпилируется это потом в выражения?
Не обязательно.
Это вопрос уже не к языку, а к компилятору.
Вы можете сами ответить, если посмотрите стр. 178 рис. 108 в книге drakon.su/_media/24_zhizneritm20.pdf
«Программирование микроконтроллеров на ДРАКОНе».
После статьи 4 видео и 279 комментариев.
we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html
В статье Ефанова и в комментариях к ней можно найти ответы на некоторые (конечно, не на все, а только на некоторые) вопросы и сомнения, которые прозвучали выше.
С уважением В. Паронджанов
Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов?