Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.
Я уже излагал.
Но их проигнорировали.
Datalog, SQL, EBNF,... и много что еще на дракон не ложатся. Совсем.
Что делает дракон применимым только в очень ограниченном классе задач, которые решаются конечными автоматами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, LaptevVV, Вы писали: LVV>Ну, мы исходим из того, что они говорят правду. Конечно, можно наворотить целое психологическое исследование...
Простите, но вы собственно психологическое исследование и провели. Никакого ответа про понятность видов представления
Правильный вариант был бы такой: разделить студентов на N групп и дать им ознакомиться с неким алгоритмом (например, балансировка AVL-дерева). Каждой из N групп дают алгоритм в одном из видов:
— текстовое описание
— псевдокод
— блок-схема
— схема на Драконе
Затем все группы сдают какой-нибудь тупой тест на понимание описанного алгоритма. Строго один и тот же. Ну там — воспроизвести алгоритм для конкретных входных данных, или ответить на вопрос типа "в каких случаях алгоритм делает то-то", или "какова сложность алгоритма в терминах O-нотации относительно размера входных данных".
Так, чтобы можно было убедиться, что студент реально понял алгоритм.
И вот после этого можно пытаться строить корреляции между полом, возрастом, способом изложения.
А вы ничего не измерили.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, roro, Вы писали:
C>>>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно. R>>Можно пример, в каком месте вывернет? C>Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее.
В случае монопольного использования процесса не вижу проблем.
Если имитировать конкурентное исполнение то да но тут больше вопросов к реализации чем к представлению
R>>Например так создают AI и постановочные сцены в популярных игровых движках. C>Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?).
Можно сделать вполне достойный "умный" уровень, описать его на тригерах и bahvaior tree, все необходимые компоненты доступны из редактора.
В CryEngine допустим добавляем солдата на карту.
У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z".
На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z".
Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").
Собственно таким способом можно сделать не хуже чем на С++.
В менее мощных редакторах MOD-мэйкеры, умудряются имитировать массивы и переменные.
Расставляют невидимые объекты на карте, кодируют адрес обьекта координатами (X,Y), значения типом объекта (танк=1 мотоцикл=2)
Не исключено что какой нибудь умелец таким образом небольшой автомат или граф закодировал.
R>>Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории). C>И?
В коде этого не видно. Конечно callgraph в проекте бывает откроешь на проблемной функции и "емана*от" ассоциация, но это совсем не то.
C>Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью.
С продуктами Rational вообще печальный опыт работы. Это какие-то рабские галеры а не серебряные пули.
C>>>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины? R>>Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину C>И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения.
Меньший процент относительно общего кода не делает state-машину ненужной или менее важной. По мне так это даже хорошо, чем меньше логики тем проще и надежнее.
C>Я понимаю, у наивных авторов, которые не писали ни строчки реального кода, установка TCP соединения, видимо, будет в виде диаграмки в полстранички.
И это хорошо
Тема case программирования и ее роль в обществе меня если честно мало интересует.
Более интересно создание графических DSL-ей и описание алгоритмов визуально.
Re[10]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, roro, Вы писали:
C>>Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее. R>В случае монопольного использования процесса не вижу проблем. R>Если имитировать конкурентное исполнение то да но тут больше вопросов к реализации чем к представлению
Ещё раз, читай про сопрограммы и событийное программирование. И почему сопрограммы намного удобнее. Они имеют очень слабое отношение к конкурентности.
R>>>Например так создают AI и постановочные сцены в популярных игровых движках. C>>Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?). R>Можно сделать вполне достойный "умный" уровень, описать его на тригерах и bahvaior tree, все необходимые компоненты доступны из редактора.
И?
R>Собственно таким способом можно сделать не хуже чем на С++.
Нельзя.
R>В менее мощных редакторах MOD-мэйкеры, умудряются имитировать массивы и переменные. R>Расставляют невидимые объекты на карте, кодируют адрес обьекта координатами (X,Y), значения типом объекта (танк=1 мотоцикл=2) R>Не исключено что какой нибудь умелец таким образом небольшой автомат или граф закодировал.
Тут кое-кто сделал эмулятор процессора 6502 в Майнкрафте. http://hackaday.com/2012/05/20/building-a-6502-in-minecraft/
И графический калькулятор там же: http://www.youtube.com/watch?v=wgJfVRhotlQ
Что неудивительно — сделать Тьюринг-полную систему элементарно. Вопрос о том, чтобы сделать её УДОБНОЙ для программиста.
R>В коде этого не видно. Конечно callgraph в проекте бывает откроешь на проблемной функции и "емана*от" ассоциация, но это совсем не то.
Прекрасно видно. Я нажимаю Find Usage и вижу кто там меня вызывает — в виде простого списка.
Callgraph реально неудобен, если в нём хотя бы пара уровней вложенности.
C>>Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью. R>С продуктами Rational вообще печальный опыт работы. Это какие-то рабские галеры а не серебряные пули.
И так со ВСЕМИ графическими средами.
C>>И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения. R>Меньший процент относительно общего кода не делает state-машину ненужной или менее важной.
Делает. Так как в РЕАЛЬНОЙ жизни получится или 5 квадратиков с 10 килобайтами кода в каждом, или 1000 квадратиков, образующих Ктулху.
R>По мне так это даже хорошо, чем меньше логики тем проще и надежнее.
Ага. Потому никаких реальных программ на ДРАКОНе и не было написано. И не будет.
Sapienti sat!
Re[13]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, LaptevVV, Вы писали:
LVV>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...
Не рисование, а автогенерация этих диаграмм из кода. Если делать автогенерацию диаграмм из кода, то во многих случаях эти диаграммы полезны, ибо действительно в некоторых случаях получается нагляднее. Особенно если это встроено в среду разработки, совмещено с навигацией по коду. Если же сначала рисовать диаграммы, то польза получается только в освоении бюджета и в том, что кто то в результате руководит большим количеством человек, благодаря чему резюме смотрится круче и проще получить повышение. Если же рисовать это все вручную — проклянешь все на свете, не важно в какой среде.
Re[8]: Язык ДРАКОН — новая идея в программировании
К>>>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?
ВП>>Да, есть. В драконе есть аналоги структурных диаграмм UML (диаграмм поведения). Если говорить более точно:
Уважаемый Курилка, Вы правы. Слово "структурный" я зачеркнул.
ВП>>Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).
ВП>>Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.
К>Всё это выглядит очень странно, если учесть, что диаграммы поведения НЕ являются структурными диаграммами, а являются одним из вариантов диаграмм взаимодействия (причём в цитате об этом есть упоминание). Да даже и смешивать в одну кучу диаграммы поведения и взаимодействия (как это сделано в вашей цитате) некорректно, ибо это разные диаграммы и акцент в них делается на разные аспекты программы.
К>Интересно всё ж услышать ответ на мой вопрос
1. Слово "структурный" я удалил.
2. Прошу прощения, в Ваш текст вкралась опечатка. Вы пишите: "диаграммы поведения НЕ являются структурными диаграммами, а являются одним из вариантов диаграмм взаимодействия". В действительности все наоборот: диаграммы взаимодействия являются одним из вариантов диаграмм поведения.
3. В драконе есть средства для работы в реальном времени, поэтому упомянута диаграмма синхронизации (timing diagram).
С уважением В. Паронджанов
Re[15]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, LaptevVV, Вы писали:
LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
И какой из этого следует вывод, учитывая, что в разработке 99% мужчин? Типа заставим мужчин помучиться, чтоб одному проценту жилось получше? Как по мне, эта только что приведенная статистика — хороший аргумент за то, чтобы ни при каких обстоятельствах не заниматься визуализацией алгоритмов, ибо визуализация наоборот будет затруднять понимание для тех, кто реально будет этим заниматься. Или кто думает, что переход на блок схемы привлечет в отрасль женский пол? Спешу огорчить — не привлечет, для привлечения нужно не на блок схемы переходить, а подход к воспитанию мадемуазелей менять.
Re[10]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, roro, Вы писали:
R>В CryEngine допустим добавляем солдата на карту. R>У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z". R>На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z". R>Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").
Вот тут вы небольшой кусочек AI записли в виде текста, а почему же вы не нарисовали его в виде графической диаграммы? Ведь если верить продвигателям визуального программирования это проще, быстрее и эргономичнее.
Re[3]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Здравствуйте, Курилка, Вы писали:
К>>Всё это выглядит очень странно, если учесть, что диаграммы поведения НЕ являются структурными диаграммами, а являются одним из вариантов диаграмм взаимодействия (причём в цитате об этом есть упоминание). Да даже и смешивать в одну кучу диаграммы поведения и взаимодействия (как это сделано в вашей цитате) некорректно, ибо это разные диаграммы и акцент в них делается на разные аспекты программы.
К>>Интересно всё ж услышать ответ на мой вопрос
ВП>1. Слово "структурный" я удалил.
никакого удаления НЕТ) и пытаетесь при этом вести диалог, то я пас
ВП>2. Прошу прощения, в Ваш текст вкралась опечатка. Вы пишите: "диаграммы поведения НЕ являются структурными диаграммами, а являются одним из вариантов диаграмм взаимодействия". В действительности все наоборот: диаграммы взаимодействия являются одним из вариантов диаграмм поведения.
Нет там никакой опечатки, там написано, что диаграммы поведения есть вид диаграмм взаимодействия, если с русским языком проблемы, то я ничем помочь не могу
ВП>3. В драконе есть средства для работы в реальном времени, поэтому упомянута диаграмма синхронизации (timing diagram).
Вопрос был про структурные диаграммы.
Конструктивных ответов на конкретно заданные вопросы от вас нет, а демагогия мне не интересна, лично для себя мнение о драконе и его апологетах я составил, поэтому дискуссию прекращаю.
Re[4]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
R>>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик. C>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.
Текстовое представление именно в этом сценарии — вообще нечитаемая абракадабра, если много ветвлений. Что в тексте плохо — необходимо помещать в памяти целиком огромные куски функциональности, чтобы понимать текст программы. Поэтому изучение чужой программы — это всегда движение по кругу, на каждом обороте проясняешь для себя что-то новое и лучше понимаешь логику, которую хотели передать в исходном тексте или ошибки в этой логике. На разбор чужого кода в тексте запросто могут уйти часы, а в графике — всегда считанные минуты.
Re[3]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот я сейчас подсчитал, в одном небольшом проекте, над которым я работаю сейчас 254845 строчек кода. Ну а теперь представьте себе схему с таким количеством иконок. Как думаете их среда разработки выдержит размер поля в 50400х35280 пикселей? (примерно столько понадобится для отрисовки такого количества иконок)
А что мешает организовать иерархию?
Сколько относительно независимых модулей, столько и будет диаграмм. Для программы указанного тобой твоего размера — это порядка несколько десятков/сотни относительно самостоятельных модулей. В больших программах счет идет на тысячи (с учетом всех внутренних библиотек).
Re[4]: Язык ДРАКОН — новая идея в программировании
V>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи. C>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Можно ли устранить этот недостаток? Можно ли облегчить жизнь алгоритмистов и программистов? И поднять производительность их труда? Да, можно.
ВП>Изюминка в том, что Дракон — очень легкий язык. Необыкновенно легкий.
Здравствуйте, elmal, Вы писали:
E>Предположим, Драконом пользуются для написания реальных программ E>Несколько вопросов: E>1) Системы контроля версий. Насколько удобно сделать diff между произвольными ревизиями кода?;
Это вопрос не к языку, а к реализации. Существующие реализации этого пока не умеют.
E>2) Насколько удобно закомментировать какую ветку или часть кода, насколько легко это все вынести в отдельную процедуру?;
Это возможно и удобно.
E>3) Книгу я просмотрел очень мельком, все примеры там бытового характера. А вот в реальности насколько удобно рисовать эти диаграмки?
Сами диаграммки высокого качества. Удобство рисования зависит от реализации (инструментальных средств). Сегодня доступны две реализации: Тышова и Митькина. К ним у пользователей есть претензии. Но они постоянно совершенствуются.
E>Отображают ли эти диаграмки полностью структуру программы с полной детализацией, или же за детализацией нужно нажимать кучу клавиш, переменные скрыты и размазаны, и чтоб реально понять что как работает, придется очень сильно потрудиться?
Посмотрите видео и составьте свое мнение. Язык позволяет, а реализация пока не всегда совершенна.
E>Спрашиваю это все потому, что визуальными средствами написания программ я пользовался на практике и в реальных проектах. И могу сказать, что обплевался. Простейшие рефакторинги делать крайне затруднительно. На диаграмме не все, чтобы увидеть детали, надо нажимать на прямоугольник и смотреть проперти.
Понимаю Вас.
E>А если детализация ого-го, то схема крайне перегружена и ее хрен разберешь.
На Драконе перегрузки нет. Используется продуманная система декомпозиции.
E>Дополнительно, пока какой управляющий блок набьешь, проклянешь все на свете. diff ни хрена ни сделать — если что работало, кто то что то поменял, и работать перестало, хрен докопаешься до причины. Перед использованием всего этого требуется проходить черти какой инструктаж, ибо куча неочевидных моментов.
E>Я видел кучу рекламных роликов о том, что вот, наконец то, появился новый язык, программисты не нужны, специалисты в предметной области сами все напишут. И в 100 процентах случаев заканчивалось тем, что приходится привлекать программистов, несмотря на наглядность читаемого представления, эти программисты страшно матерятся, тратят в 10 раз больше времени, а также программистов требуется в 10 раз больше. Ибо кроме того, что это все крайне неудобно использовать на практике, еще и среда разработки страшно глючит, а также при малейшем отклонении от идеального эталонного сценария приходится делать такие извраты и макароны, что появляется желание уйти в запой с горя. А если в самом начале в какой либо переменной допустил орфографическую ошибку — все, это уже практически не исправить. Средств рефакторинга нет, чтобы выделить процедуру, нужно ее рисовать с нуля. Даже переменную переименовать проблема, приходится реплейсить внутреннее представление этой схемки, никому не говоря, ибо это запрещено. В результате, учитывая то, что рефакторить крайне затруднительно, на практике код очень быстро превращается в черти какие макароны, когда на одной схеме тысячи стрелочек и блоков, налезающих друг на друга.
На Драконе никакие макароны В ПРИНЦИПЕ не возможны.
Я четко сознаю, что не ответил на Ваши вопросы. На такие вопросы нельзя ответить словами.
Надо предъявлять рабочий инструмент. Так что могу сказать одно — посмотрите видео.
В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА), то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.
С уважением В. Паронджанов
Re[5]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи. C>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают. V>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.
Никаких независимых подтверждений его слов нет. Так же как и вообще известного софта или работающих реализаций самого языка.
Sapienti sat!
Re[5]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА), то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.
Вы врёте. У вас нет даже реализации ДРАКОНа на ДРАКОНЕ, как и любой другой сколь-либо сложной программы. И не будет.
Sapienti sat!
Re[5]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Посмотрите видео и составьте свое мнение. Язык позволяет, а реализация пока не всегда совершенна.
Посмотрел. Как я и ожидал — диаграмки являются по существу комментариями, отражающими структуру кода, а не детали. А чтобы посмотреть детали — нужно нажимать на прямоугольничек и откроется область кода. Напомнило все до боли Rational Rose. Соответственно — на диаграмке может все казаться правильно, а в реализации можно элементарно ошибиться. А чтоб реально быть уверенным, что все правильно, нужно долго и очень внимательно смотреть именно что результирующий код. Который несколько далек от идеала благодаря автогенерации.
ВП>На Драконе перегрузки нет. Используется продуманная система декомпозиции.
Угу, самые важные детали (а как же именно мы реализовываем отключение компаратора, как пример) скрываются и на диаграмме не видны. А на практике при рефакторинге мы можем случайно в реализации вместо отключения компаратора послать команду на запуск маршевых двигателей. А если их там показывать — схема разрастется до огромных размеров, либо потребуется делать дикую декомпозицию и постоянно переключать внимание между различными диаграммами.
ВП>На Драконе никакие макароны В ПРИНЦИПЕ не возможны.
Макароны возможны всегда! Это не зависит от языка, от методологии! Или просто сложность одной процедуры ограничена определенными размерами? Все равно не спасет, ибо можно что угодно запутать глобальными переменными, связями все со всем.
ВП>Надо предъявлять рабочий инструмент. Так что могу сказать одно — посмотрите видео.
Видео посмотрел. До боли напомнило все Rational Rose. Точнее даже не ее, а какое то другое CASE средство 1998 года.
ВП>В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА), то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.
Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000. Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов. По поводу понятности. Хорошо — пусть будут Дракон схемы для визуализации алгоритмов! Непонятно, чем он лучше других подобных языков, вроде UML, но ладно — предположим что по наглядности визуализации Дракон лучший. Так вот, чтоб этой понятностью реально пользоваться, нужно наоборот все делать! Нужно сначала реализовывать алгоритм на любом языке, помечать его соответствующими комментариями, и на основании комментариев и исходного текста путем реверс инжинеринга визуализировать Дракон схемы, добиваясь того, чтобы было все читабельно. Делать такую поддержку для всех языков и всех известных сред разработки через плагины. В этом случае какие то перспективы есть.
но тут больше вопросов к реализации чем к представлению
