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


V>>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
S>Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.

Ну не я же, ес-но... )))
Задачу поставил ДРАКОН, а на текстовом уровне — ограничения СП.



V>>Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.
S>Ты говоришь "нужно избавиться от перекрестков"
S>Я — "давай поставим развязку с мостом"
S>Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
S>Конечно се ля ви. Так чего ради избавлялись от перекрестков?

Гм... сорри, многоуровневая развязка как-раз уже была.

Ведь эти пересечение существуют только на 2D-схеме, но "контакта" линий на самом деле НЕТ. Можно изобразить схему в 3D, задав для разных блоков разные уровни, и убедиться.

То, что предлагаешь ты, Дейкстра и автоматный подход к решению задач — это вместо независимых многоуровневых развязок сделать один кольцевой перекрёсток с десятками примыкающих к нему дорог. Как в реальной жизни, так и в IT на этом кольце всегда тормоза.

V>>Отсылка была конкретно к циклу работы ЦП, т.е. к тому факту, что хотя цикл ЦП можно выразить без пересечений, этот ЦП способен выполнять алгоритмы наподобие тех, блок схему одного из которых я привел. До сих пор не понятна аналогия работы ЦП? Или мне надо раскрыть сам цикл работы ЦП?
S>Да какой там цикл? Весь цикл, который необходим на данном уровне абстракции — взять команду и выполнить.

Ну дык, так же работает ЦП.

S>Но в общем случае ЦП довольно нетривиальная вещь и я не понимаю, о каком цикле работы ты говоришь.

Да я уже понял, что не понимаешь... Хотя не мог в это поверить несколько постов. Фиг с ним, считаем что аналогия была неочевидной.


V>>Ограничения структурного программирования предназначены для человека, а не машины.
S>Вот поэтому и избавляются от goto

Не поэтому. Мы тут обсуждаем ту самую тонкость в отличии стратегии от конкретного шага. Для 99% (грубо) случаев наличие goto означает плохую структуризацию алгоритма. Поэтому, стратегия избавления от goto — хорошая, правильная стратегия. Но знаешь, как в играх, наподобие шахмат, реверси и т.д. — если игрок не способен найти оптимальное решение для конкретной ситуации, то использует некую стратегию. Т.е. действует по-сути вслепую, "согласно инструкции". А если может найти наилучшее решение для конкретной ситуации — то стратегия уже не является определяющей в решении хода.


V>>А как вообще работает ЦП?
S>Я не спец по ЦП. Мне достаточно того что он выполняет команды. Даже о том что он их интерпретирует мне знать не надо.

В общем, он тоже работает в таком же цикле диспетчеризации со многими одноуровневыми ветвлениями из одной точки — начала цикла.


V>>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
S>Тебе не удалось мне это показать.

Это даже где-то обидно.
"Воображение важнее знания" (С) Энштейн.

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

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


V>>>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
S>>Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.

V>Ну не я же, ес-но... )))
V>Задачу поставил ДРАКОН, а на текстовом уровне — ограничения СП.

Во! Т.е. исключительные закидоны программиста превращаются в закидоны ДРАКОН-а и СП.


S>>Ты говоришь "нужно избавиться от перекрестков"
S>>Я — "давай поставим развязку с мостом"
S>>Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
S>>Конечно се ля ви. Так чего ради избавлялись от перекрестков?

V>Гм... сорри, многоуровневая развязка как-раз уже была.
Да, верно. Я привел не ту аналогию.

V>Ведь эти пересечение существуют только на 2D-схеме, но "контакта" линий на самом деле НЕТ. Можно изобразить схему в 3D, задав для разных блоков разные уровни, и убедиться.
Тсссс! Если ДРАКОН станет 3D, то это будет финиш всему.

V>То, что предлагаешь ты, Дейкстра и автоматный подход к решению задач — это вместо независимых многоуровневых развязок сделать один кольцевой перекрёсток с десятками примыкающих к нему дорог. Как в реальной жизни, так и в IT на этом кольце всегда тормоза.
Верно.

S>>Но в общем случае ЦП довольно нетривиальная вещь и я не понимаю, о каком цикле работы ты говоришь.

V>Да я уже понял, что не понимаешь... Хотя не мог в это поверить несколько постов. Фиг с ним, считаем что аналогия была неочевидной.
угу

S>>Вот поэтому и избавляются от goto

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

V>В общем, он тоже работает в таком же цикле диспетчеризации со многими одноуровневыми ветвлениями из одной точки — начала цикла.
Там есть небольшое отличие. ЦП может крутиться в цикле, но он лишь исполняет код, а не управляет диспетчеризацией. А алгоритм с циклом сообщений сам управляет своим ветвлением.

V>>>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
S>>Тебе не удалось мне это показать.

V>Это даже где-то обидно.
V>"Воображение важнее знания" (С) Энштейн.
Я от пересечений избавился. Как и Дейкстра. Просто ты утверждаешь что если вернуть все обратно, то пересечения все равно будут. Конечно будут. Но в модифицированном алгоритме их нет. Пусть и ценой значительного усложнения. Не упрощай обратно и пересечений не будет.

А в разговор о том, что кому лучше, пересечения или цикл сообщений, я не ввязывался

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

W>Здравствуйте, Владимир Паронджанов,

W>хороший язык и отлично что на нем пишется софт для космоса,
Интересно, а не нём ли писали софт для Фобос-грунта?

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

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

W>>Здравствуйте, Владимир Паронджанов,

W>>хороший язык и отлично что на нем пишется софт для космоса,
K>Интересно, а не нём ли писали софт для Фобос-грунта?
Вроде как НПО Лавочкина ГРАФИТ-ФЛОКСОМ не пользуется... только Пилюгинский центр... Про софт для ФГ jбсуждалсь — можно в этой ветке глянуть.

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


V>>А вообще, использование формального языка для постановки задачи — это на самом деле 5 баллов! Вы просто малость не в ту сторону смотрите и не то желаете там увидеть.
VD>Ага. Только языки эти не могут быть одним языком. Они разные. Как на драконе парсер описать? А как 3d-объект?

Тебе надо описать грамматику парсера или его механику? Как раз механику любого парсера, в том числе вашего TDOP описать без проблем, это же обычный алгоритм.

Что такое "описать 3d объект" я не понял. Если речь о внешнем виде — то 3D объекты "описывают" в проекциях и/или изометриях/аксонометриях. ДРАКОН предназначен для алгоритмической части описания.

==============================
Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%. Это вообще как??? ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

V>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%. Это вообще как??? ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

Нет, ты видишь не эту картину. Картина здесь диаметрально противоположная. Приходит очередной просветитель П со свей панацеей ПЦ, несет околесицу и ахинею, не отвечает на простейшие вопросы, и сливается.

Что характерно, обычно такие П и ПЦ обитают на oberoncore, что характерно

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

V>Тебе надо описать грамматику парсера или его механику? Как раз механику любого парсера, в том числе вашего TDOP описать без проблем, это же обычный алгоритм.

И то, и другое. Нам надо описывать конкретные грамматики и генерировать по ним эффективный код. Последнее крайне не тривиально. Во-первых нужно гарантированно генерировать низкоуровневый код. Во-вторых, нужно генерировать специализированный код для разных сочетаний случаев.

V>Что такое "описать 3d объект" я не понял.

А то и значит. Видел такие программы как 3DS Max? У них свои языки описания объектов и дизайнеры для их рисования. Потом эти объекты нужно в программу загружать и использовать. Соответственно как-то надо ее представлять.

V>Если речь о внешнем виде — то 3D объекты "описывают" в проекциях и/или изометриях/аксонометриях. ДРАКОН предназначен для алгоритмической части описания.

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

V>==============================
V>Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

V>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%. Это вообще как???

Наверно орлы не согласны с твоими оценками процентных отношений.

V>ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

VD>Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

Ну, оно у них используется, как DSL.

Есть Дракон, манипулирующий высокоуровневыми объектами.
Есть Флокс, который является базой данных этих объектов.

Итог — полуавтоматическая связка этих объектов, используя связи из Драконовской схемы.

Все. Вне этой схемы Дракон бесполезен для программирования чуть более, чем полностью.

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

M>Ну, оно у них используется, как DSL.

ДСЛ не может быть на все случаи жизни. Весь смысл ДСЛ-ей в том, что под каждую задачу создается свой язык. Наличие ДСЛ для одной задачи ни разу не повышает уровень программирования в целом.

M>Все. Вне этой схемы Дракон бесполезен для программирования чуть более, чем полностью.

А мог бы создавать новые ДСЛ-и и проблем со сменой схем не было бы.

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

V>>Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

V>>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%. Это вообще как???

VD>Наверно орлы не согласны с твоими оценками процентных отношений.

Орлов тошнит от самого термина ТЗ. А с оценками они согласны, не боись.


V>>ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.
VD>Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.
Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

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

Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

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

V>Орлов тошнит от самого термина ТЗ. А с оценками они согласны, не боись.

Ты бы у них, что ли, спросил.

V>Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.

Императивный ДСЛ — это примерно тоже самое как соленый леденец. Сделать можно, но зачем он нужен не ясно.

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

Это махровое заблуждение. Попробуй на досуге представить в виде блок-схем или диаграмм грамматику какого-нить языка или описание 3D-объекта.

Я помню, что в школе информатику как раз и начинали преподавать с блок-схем.

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

V>>Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.
VD>Императивный ДСЛ — это примерно тоже самое как соленый леденец. Сделать можно, но зачем он нужен не ясно.

Затем же, зачем любой другой ДСЛ — для описания программы в терминах предметной области.


VD>Попробуй на досуге представить в виде блок-схем или диаграмм грамматику какого-нить языка

Как раз ваш TDOP — это обычный императивный алгоритм.


VD>или описание 3D-объекта.

Про 3D я тебе уже отвечал.

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

M>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

Угу, а ты на sequence-диаграмме покажи ветвление по условию.

M>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

V>Угу, а ты на sequence-диаграмме покажи ветвление по условию.

Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

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

M>>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?
V>>Угу, а ты на sequence-диаграмме покажи ветвление по условию.
M>Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

Типичная sequence diagram показывает глупым программистам упрощенную схему взаимного поведения нескольких независимых программ, а ДРАКОН преназначен для написания каждой из них. Ты никак не получишь из sequence diagram исходник для каждой программы, упомянутой в диаграмме.

M>>>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?
V>>>Угу, а ты на sequence-диаграмме покажи ветвление по условию.
M>>Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

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

Мне не надо получать из sequence диаграмм исходники «программ».

Не говоря о том, что sequеnce диаграммы используются не только для схем поведения независимых программ. Для параллельно выполняющихся компонентов одной программы в распределенной среде sequence diagram подходит как нельзя лучше. Только вот на Драконе описать взаимодействие таких компонентов невозможно.

Ах, и да. Вернемся к твоему заявлению:

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

Итак, повторю вопрос: как мне создать sequence диаграмму для протокола. Ведь описание протокола зачастую описывает, что происходит в разных независимых программах...

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

M>Мне не надо получать из sequence диаграмм исходники «программ».

Тогда это артефакт для менеджеров.

M>Не говоря о том, что sequеnce диаграммы используются не только для схем поведения независимых программ. Для параллельно выполняющихся компонентов одной программы в распределенной среде sequence diagram подходит как нельзя лучше.

В распределенной среде у тебя разве не разные инстансы программ? В принципе, даже если в речь о разных потоках одного процесса, то... То в классике потоки — это легковесные процессы. Поэтому зря ты пытаешься придираться к словам. Тем более, что на сегодня грань м/у "программами" и "компонентами" весьма умозрительна.


M>Итак, повторю вопрос: как мне создать sequence диаграмму для протокола. Ведь описание протокола зачастую описывает, что происходит в разных независимых программах...

Не факт. Описание протокола может декларировать поведение каждого из ендпоинтов. Особенно это хорошо подходит для симметричных (хотя бы частично) протоколов. Например, фиг ты с помощью sequеnce диаграммы опишешь логику вокруг ширины окна в TCP. Или, например, при конкурентном симметричном доступе к ресурсам (сетка по коаксиалу) sequence-diagram не столь хороша для описания происходящего, как обычный алгоритм с ветвлением, описывающий только одного участника.

M>>Мне не надо получать из sequence диаграмм исходники «программ».

V>Тогда это артефакт для менеджеров.

Нет. Это — полезный инструмент для высокоуровнего планирования взаимодействия компонентов.

M>>Не говоря о том, что sequеnce диаграммы используются не только для схем поведения независимых программ. Для параллельно выполняющихся компонентов одной программы в распределенной среде sequence diagram подходит как нельзя лучше.

V>В распределенной среде у тебя разве не разные инстансы программ?

Не обязательно.

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

Не пытайся выкрутиться нагромождением слов.

Итак, у нас есть несколько взаимодействующих потоков. Например, простейший Map/Reduce или parallel quicksort. Покажи мне, как это показать в Драконе

M>>Итак, повторю вопрос: как мне создать sequence диаграмму для протокола. Ведь описание протокола зачастую описывает, что происходит в разных независимых программах...

V>Не факт. Описание протокола может декларировать поведение каждого из ендпоинтов. Особенно это хорошо подходит для симметричных (хотя бы частично) протоколов. Например, фиг ты с помощью sequеnce диаграммы опишешь логику вокруг ширины окна в TCP. Или, например, при конкурентном симметричном доступе к ресурсам (сетка по коаксиалу) sequence-diagram не столь хороша для описания происходящего, как обычный алгоритм с ветвлением, описывающий только одного участника.

Опять куча текста, лишь бы выкрутиться. Я не говорю, применима ли sequence диаграмма к описанию TCP. Я не говорю, о случаях, когда sequnce диаграмма неприменима. Я говорю о случаях, когда sequence диаграмма применима.

Например, http://www.uml-diagrams.org/sequence-diagrams-examples.html Диаграммы "Submit Comments to Pluck" и "Facebook User Authentication in a Web Application".