Здравствуйте, LaptevVV, Вы писали:

LVV>1. Насчет приоритета — вы передергиваете.
Нисколько. Просмотрите свои предыдущие посты. Вы там пытались доказать что рисуночки студент воспримет лучше чем мат. аппарат, а следовательно мертворожденное дряхлое дитя советской околонаучной деятельности именуемой дракон (что за бредовое название ))?) имеет смысл, будет расти и пахнуть.
LVV>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...
Угу, и PowerPaint и фотошоп. И лист бумаги. Вы только не прояснили чем лист бумаги хуже дракона.
LVV>Наши выпускники — нашей каферы.
Самое страшное для выпускников вашей кафедры, это то что они будут знать слово "дракон", но не будут знать классический курс CS. И когда они придут устраиваться на работу, над ними просто посмеются.

Салют

Здравствуйте, vl690001x, Вы писали:

V>Почему многие сразу принимаются за критику, толком не разобравшись?
Почему многие что-то придумавшие сразу принимаються за пропаганду, толком не разобравшись (чё же придумали)?
V>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
Причина банальна — человеку которому лень изучать что то уже существующее, проще придумать что то свою. Ведь когда это что то свою — то его не надо изучать, понимать что оно из себя представляет, оценивать насколько может конкурировать с аналогами и т.д.
V>Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.
Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию прорывов и будущем, а тех кто ее не продвигает — недоучками.
Но это нерационально с точки зрения здравого смысла, потому что разумно сначала изучить аналоги, выделить их недостатки и положительные черты, а уже потом делать что то новое, имеющее преимущества перед уже существующими технологиями.

V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык будет очень хорош для планшетов. А в дальнейшем я думаю появятся еще более революционные интерфейсы чем сенсорные пальце-ориентированные.
Не знаю ничего насчет именно языка ДРАКОН, слышал где-то (тут), подумал что это что-то детское бессмысленное, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык очень похож на обычные блок схемы. По ГОСТу. Которые придумали ещё до первых языков программирования. И от которых отказались. Для которых есть не одна реализация. И все реализации провалились. Что преимущества языка описаны детскими фразами "ввел термин эргономичность", "проще", "легче" и что это язык программирования для НЕпрограммистов.
И на планшеты мне кстати пофиг. И программировать в будущем я хочу не пальцами а мыслями. Ну или хотя бы голосом.

V>В конечном итоге, возможно что управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах. Конечно эти схемы будут графическими, и похожими на карты разума.
В конечном итоге мне пофиг. Но если человек заявляет лучше, мне все же интерестно в чем это абстрактное "лучше" заключаеться. Если человек говорит новый мне интерестно, чем же он отличаеться от существовавщих. Если человек говорит существующие не подходят — мне очень интерестно почему, и какие же именно.
V>Таково мое видение будущего.
Таково мое видиние настоящего.

V>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
Так что я думаю, что язык ДРАКОН вероятно не имеет будущего, уже потому, что у него нет настоящего.

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, LaptevVV, Вы писали:

LVV>>1. Насчет приоритета — вы передергиваете.
__>Нисколько. Просмотрите свои предыдущие посты. Вы там пытались доказать что рисуночки студент воспримет лучше чем мат. аппарат, а следовательно мертворожденное дряхлое дитя советской околонаучной деятельности именуемой дракон (что за бредовое название ))?) имеет смысл, будет расти и пахнуть.
Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
LVV>>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...
__>Угу, и PowerPaint и фотошоп. И лист бумаги. Вы только не прояснили чем лист бумаги хуже дракона.
Не хуже. На листе бумаги можно нарисовать Дракон-схему, и UML-диаграмму...
LVV>>Наши выпускники — нашей каферы.
__>Самое страшное для выпускников вашей кафедры, это то что они будут знать слово "дракон", но не будут знать классический курс CS. И когда они придут устраиваться на работу, над ними просто посмеются.
Опять же — вы нифига не знаете про то, что изучают наши студенты, а делаете безапелляционные выводы.
Привет вашей логике... Она даже на женскую не похожа...

Здравствуйте, WolfHound, Вы писали:

WH>Дракон-схема задает конечный автомат.

Да, это правильно. Дракон-схема задает конечный автомат. Но не только.

WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.


Уважаемый модератор WolfHound!

Если интересно, я могу переслать Вам по мейлу следующий материал (48 страниц, pdf):

Часть VII. Теоретические основы языка ДРАКОН ....................................425

Глава 34. Исчисление икон .......................................................427

Глава 35. Метод Ашкрофта-Манны и алгоритмическая структура «силуэт» .............436

Глава 36. Визуальный структурный подход к алгоритмам и программам (шампур-метод) 449

Здравствуйте, Cyberax, Вы писали:

C>Кстати, даже этот детский пример — неправильный.

C>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.

C>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.

Дык это потому, что всё на одной картинке. Вы мысленно переведите в текст (с которым мы привыкли), такое же безобразие получится. Далее вы разделите на разные функции и вуаля. Ну так и тут можно перерисовать в "иди на рыбалку, рыбачь, иди домой", где "рыбачь" — "проверь наживку, кидай, жди" ну и так далее.
Правда, смысла я в этом всём всё равно не вижу, но ваши придирки все не потому, что ДРАКОН не тот, а потому что пример уродливый.

Здравствуйте, LaptevVV, Вы писали:

LVV>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.

Это неверный вывод. Правильно будет — в опросах, девушки отвечают, что лучше воспринимают схемы, а парни отвечают, что лучше воспринимают псевдокод. Это далеко не то же самое.

Здравствуйте, Владимир Паронджанов, Вы писали:

WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.
ВП>Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.
Это правильно. Теоретически можно всё на brainfuck'е написать — так как он Тьюринг-полный. Но практически — достаточно посмотреть на его название.

Если это не так, то попрошу привести здесь алгоритм быстрой сортировки, балансировки бинарного дерева и парсера текста. Чтоб их можно было реально выполнить.

Здравствуйте, vl690001x, Вы писали:

V>Почему многие сразу принимаются за критику, толком не разобравшись?
V>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
У нормальных специалистов нет проблем с изучением очередной рвотной массы типа ДРАКОНа. В нём нового — ровно ноль. Обычный простой императивный язык, коих десятки тысяч.

До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?

V>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
Имеет — в качестве посмешища.

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, LaptevVV, Вы писали:

LVV>>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.

DR>Это неверный вывод. Правильно будет — в опросах, девушки отвечают, что лучше воспринимают схемы, а парни отвечают, что лучше воспринимают псевдокод. Это далеко не то же самое.
Ну, мы исходим из того, что они говорят правду. Конечно, можно наворотить целое психологическое исследование...
Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, мы исходим из того, что они говорят правду. Конечно, можно наворотить целое психологическое исследование...
LVV>Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

Без исследования, опрос это всего лишь опрос. Другой вывод, который из него можно сделать, это что девушки больше склонны отвечать то, что преподаватель хочет услышать (experimenter's bias). Или, что девушки более внушаемы и после курса по схематическому программированию уверены, что нашли серебряную пулю. Или, что студенты отвечают согласно сложившимся стереотипам.

Здравствуйте, Курилка, Вы писали:

К>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?

Да, есть. В драконе есть аналоги структурных диаграмм UML (диаграмм поведения). Если говорить более точно:

Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

Здравствуйте, Cyberax, Вы писали:

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
Я помню. Помню, что роза рациональная, и что она синоним абракадабрской жопы. У жопы и розы общее то, что количество букв одинаково

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, LaptevVV, Вы писали:

LVV>>Ну, мы исходим из того, что они говорят правду. Конечно, можно наворотить целое психологическое исследование...
LVV>>Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

DR>Без исследования, опрос это всего лишь опрос. Другой вывод, который из него можно сделать, это что девушки больше склонны отвечать то, что преподаватель хочет услышать (experimenter's bias). Или, что девушки более внушаемы и после курса по схематическому программированию уверены, что нашли серебряную пулю. Или, что студенты отвечают согласно сложившимся стереотипам.
1. Про девушек — это все понятно.
2. У нас нет курса по схематическому программированию.

Здравствуйте, roro, Вы писали:

C>>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
R>Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
R>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.

C>>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
R>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.

C>>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
R>Вот не надо, установить tcp соединение это уже стейт-машина примитивная.
И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?

Здравствуйте, WolfHound, Вы писали:

WH>Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА ...

Я согласен с Вами, что решение задачи в терминах предметной области — это хорошо.

На Драконе задачи прекрасно решаются в терминах предметной области. На работе я организую работу именно таким образом.

Здравствуйте, Владимир Паронджанов, Вы писали:

WH>>Дракон-схема задает конечный автомат.
ВП>Да, это правильно. Дракон-схема задает конечный автомат. Но не только.
За счет вызовов она умеет задавать КА со стеком. А что еще?

WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.
ВП>Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.
Еще раз. Полнота по Тьюрингу меня не волнует.
Меня волнует решение задачи в терминах предметной области.
Ибо только так можно достичь максимальной выразительности.

ВП>Если интересно, я могу переслать Вам по мейлу следующий материал (48 страниц, pdf):
Не интересно. Ибо КА приемлемы в очень малом наборе задач.
Мне интересно как на драконе будет выглядеть аналог кода на даталоге.
Или аналог EBNF грамматики.
Или SQL запрос.
Я могу продолжать этот список очень долго.

Поймите я не против ДРАКОНА. И возможно буду использовать его, если мне понадобится, чтобы не программисты описывали что-то что сводится к КА.
Но вы должны понять, что область применения ДРАКОНА очень узкая. И он не может быть эффективен в очень широком классе задач.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Драконе задачи прекрасно решаются в терминах предметной области. На работе я организую работу именно таким образом.
Только если предметная область сводится к КА.
А если нет, то все становится печально.

Здравствуйте, Cyberax, Вы писали:

V>>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
C>Имеет — в качестве посмешища.


Ну я бы тоже не стал его изучать, даже хотя бы из-за названия. Кроме того у меня есть предубеждение против всего на чем пилят бабки. Но направление перспективное.

Здравствуйте, vl690001x, Вы писали:

V>Почему многие сразу принимаются за критику, толком не разобравшись?
V>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
V>Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.

V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык будет очень хорош для планшетов. А в дальнейшем я думаю появятся еще более революционные интерфейсы чем сенсорные пальце-ориентированные.
V>В конечном итоге, возможно что управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах.

Уже сейчас всё гораздо круче: большая часть идей, которые зарождаются у людей в голове, заранее существует в виде формальных схем, инсталируемых в головы через зомбоящик.

V>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.

Хороший стёб

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, roro, Вы писали:

C>>>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
R>>Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
R>>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
C>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.

Можно пример, в каком месте вывернет?

C>>>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
R>>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
C>Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.

Диаграммы тут обобщенные, но хорошо иллюстрируют подход к проблеме.

Например так создают AI и постановочные сцены в популярных игровых движках.

Kismet редактор в Uneral Engine.
Flow Graph Editor редактор в CryEngine 3.

Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории).

Знаю что без фреймворка или dsl писать сложные поведения и fsm на c/c++/java/c# то еше удовольствие. А ревьюить без знания кода практически невозможно, только в случае если кто-то будет подсказывать что делает тот или другой кусок кода.

Некоторое время баловался Debugger Canvas, достаточно удобно. Если в таком-же стиле сделать редактор дракона, да с отладкой схем.
И еше добавить уровни:
1 Большие логические модули
2 Подпрограммы
3 Низкоуровневые алгоритмы

И придумать как это все сгруппировать и отобразить )

C>>>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
R>>Вот не надо, установить tcp соединение это уже стейт-машина примитивная.
C>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?

Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину