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

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

Обязательно. Даже если программа одна и та же, инстансы разные.


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

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

Агащаз. Твои постоянные попытки придираться к словам уже требуют некоторого ликбеза. Ты же вечно не на сути акцентируешься, а на какой-то фигне, конкретно здесь на якобы разнице м/у программой и компонентом. Эта разница весьма условна. И уже очень давно.

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

Это я рисовать что ле для тебя должен? Попридержи коней, парниша. Как именно раскладываются диаграммы последовательностей на алгоритмы каждого из участников курить самостоятельно. А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

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

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

На будущее: инструмент, не умеющий генерить код, а умеющий только рисовать кружочки/квадратики/линии, надо сравнивать с огрызком карандаша и обрывком туалетной бумаги. Такое сравнение было бы всяко по-адекватнее.

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

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

V>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

Как ты покажешь в драконе взаимодействие между этими участниками?

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

V>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.

А кто говорил про генерацию кода?

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

Или для тебя алгоритм — это «сел и начал фигачить код»?

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

V>На будущее: инструмент, не умеющий генерить код, а умеющий только рисовать кружочки/квадратики/линии, надо сравнивать с огрызком карандаша и обрывком туалетной бумаги. Такое сравнение было бы всяко по-адекватнее.

ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.

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

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

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

V>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

M>Как ты покажешь в драконе взаимодействие между этими участниками?
Сам ВП предлагал два варианта: 1) как раскрыть свои же Z-операторы в этом посте — через работу в "точном времени"; 2) как представить обмен сообщениями — через оператор И20 (отправка сообщений; пример приложения дал Р. Блинов в этом посте на третьей схеме; нужен парный оператор приёма сообщений).

M>>Как ты покажешь в драконе взаимодействие между этими участниками?
VZ>Сам ВП предлагал два варианта: 1) как раскрыть свои же Z-операторы в этом посте — через работу в "точном времени"; 2) как представить обмен сообщениями — через оператор И20 (отправка сообщений; пример приложения дал Р. Блинов в этом посте на третьей схеме; нужен парный оператор приёма сообщений).

Первую ссылку видел в первом пункте видел, остальные еще нет. Увы, большой наглядности предложенные варианты не предлагают

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

M>Первую ссылку видел в первом пункте видел, остальные еще нет. Увы, большой наглядности предложенные варианты не предлагают

Это да. Но тут хотя бы отделяются доалгоритмические вещи (схемы деятельности для двух и более исполнителей) от алгоритмических (процессы, для каждого из которых можно указать единственного исполнителя)...

И ведь дело в том, что сначала идёт содержательное (а ещё раньше — целевое, т.е. прагматика)... а потом уже думаем, как бы это понагляднее представить...

А в ряде традиционных способов формализации вообще интересно. Скажем, GAN, который уже упоминал. Там есть алгебра схем — ну как в схемах ТАУ можно приводить граф вместе с разметкой. Но из изложения можно понять, что главная прагматика всего этого — "упрощение выражений" так, чтобы можно было получить сокращённую формулу расчёта величин разметки (там параметры трудоёмкости). Можно при определённых условиях всю исходную сеть работ свернуть до одной вершины, при этом параллельные преобразования разметочных выражений дадут формулу для вычислений той же трудоёмкости... Однако насколько это помогает понять ход деятельности, которую описывает исходная сеть?.. К семантике схем есть вопросы... Не говоря о том, что эта работа требует "GAN-алгебраиста"...

Как уже понятно, видимо, я не фанат ни ДРАКОНа, ни Оберона, скажем. Мне нужны средства представить реальную деятельность — я их подбираю. Если возможно — что-то модифицируя... В этом процессе, разумеется, интересны любые спокойные содержательные мнения.

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

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

V>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.
M>Как ты покажешь в драконе взаимодействие между этими участниками?

Хоть в Драконе, хоть в привычных блок-схемах будет один и тот же эффект... Неужели сам не догадался, что, в случае сложного поведения сторон + передающей среды, всяко дешевле будет показать поведение каждой стороны по-отдельности, чем полный комбинаторный набор ситуаций взаимного поведения сторон, сдобренного эффектами среды. Во втором случае это будет произведение всех if-ов всех участников.


V>>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.
M>А кто говорил про генерацию кода?

Тут говорят.


M>

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

M>Или для тебя алгоритм — это «сел и начал фигачить код»?

1. ответ нет.
2. при чем тут своё "или"? фраза вышла нерелевантной.


M>ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.

Да, какие проблемы автоматизировать кодогенерацию? Не писал никогда генерилок кода из "левого", по отношению к целевому коду, описания?

V>>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.
M>>Как ты покажешь в драконе взаимодействие между этими участниками?

V>Хоть в Драконе, хоть в привычных блок-схемах будет один и тот же эффект... Неужели сам не догадался, что, в случае сложного поведения сторон + передающей среды, всяко дешевле будет показать поведение каждой стороны по-отдельности, чем полный комбинаторный набор ситуаций взаимного поведения сторон, сдобренного эффектами среды. Во втором случае это будет произведение всех if-ов всех участников.

Набор не обязательно комбинаторный.

V>>>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.
M>>А кто говорил про генерацию кода?

V>Тут говорят.

Про нее говоришь только ты, и только тогда, когда тебе нужно. Смотрим твою цитату ниже. Если Дракон — способ описания протоколов/алгоритмов, то генерация кода не обязательна.


M>>

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

M>>Или для тебя алгоритм — это «сел и начал фигачить код»?

V>1. ответ нет.


Если ответ — нет, то попрошу аналоги слежующего для Дракона: http://www.uml-diagrams.org/sequence-diagrams-examples.html


M>>ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.
V>Да, какие проблемы автоматизировать кодогенерацию? Не писал никогда генерилок кода из "левого", по отношению к целевому коду, описания?

«"Левого", по отношению к целевому коду, описание» — это как раз описание алгоритма. Пример описания алгоритма: http://www.uml-diagrams.org/sequence-diagrams-examples.html Седьмое, по-моему, сообщение подряд прошу показать мне аналог на Драконе.

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

V>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

А "Фобос-Грунт" на чём делали?..

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

C>"Программирование светофора"?

IMHO, ты зря ёрничаешь. Сделать систему, которая позволяет программировать сыетофор/светофоры перекрёстка/улицы/микрорайона и при этом позволяет легко обучить это делать офицера ГИБДД, а не выпускника мехмата -- не такая уж и простая задача, особенно если учесть, что надо обеспечить высокий уровень безопасности ДД и непротиворечиывость на границах участков...

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

E>Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000. Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов.

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


E>По поводу понятности. Хорошо — пусть будут Дракон схемы для визуализации алгоритмов! Непонятно, чем он лучше других подобных языков, вроде UML,
UML не позволяет записать алгоритм.

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

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

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

E>IMHO, ты зря ёрничаешь. Сделать систему, которая позволяет программировать сыетофор/светофоры перекрёстка/улицы/микрорайона и при этом позволяет легко обучить это делать офицера ГИБДД, а не выпускника мехмата -- не такая уж и простая задача, особенно если учесть, что надо обеспечить высокий уровень безопасности ДД и непротиворечиывость на границах участков...

Ты зачем достал ветку двухгодовой давности?

Здравствуйте, alpha21264, Вы писали:
A>Ты зачем достал ветку двухгодовой давности?

Дракон еще не издох ?

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

A>Ты зачем достал ветку двухгодовой давности?

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

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

E>А "Фобос-Грунт" на чём делали?..

Откопал, блин. Закапывай обратно.

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

Ops>Откопал, блин.
Сам не рад. Перешёл по какой-то ссылке от Лаптева и только после ответа заметил, что оно двухлетнее уже...


Ops>Закапывай обратно.
А как это сделать?
И, кстати, краткое резюме-то какое?
ДРАКОН-то реально на "Буране" использовали?
И Бату там реально работал или как обычно рапортует из параллельной реальности?

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

E>А как это сделать?

E>И, кстати, краткое резюме-то какое?
Это секта.
E>ДРАКОН-то реально на "Буране" использовали?
E>И Бату там реально работал или как обычно рапортует из параллельной реальности?
Я тогда забил на этот флейм, так и не разобравшись.

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

Ops>Это секта.
Ну. так это же и прикольно!
Вон немерле, например, тоже секта

Ops>Я тогда забил на этот флейм, так и не разобравшись.
Я вот тоже не осилю, похоже...

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

Ops>>Это секта.
E>Ну. так это же и прикольно!
E>Вон немерле, например, тоже секта
Так немерлю делают хотя бы, а тут только восхваляют.

Ops>>Я тогда забил на этот флейм, так и не разобравшись.
E>Я вот тоже не осилю, похоже...
А надо?

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

Ops>>А ты вот это http://www.rsdn.ru/forum/flame.comp/4086890.aspx

Автор: PC_2
Дата: 21.12.10

застал?
Т>А как же!
Т>Я даже под опусы Сергея "Синтаксический Оверхед" Губанова изволил откушать.
Т>Мы, тролли — древний народ

Да тут каждые пару лет очередное гениальное решение из этой же серии вылезает. Лаптев тоже, помнится, похожее задвигал. А первое из таких решений мне на глаза попалось ещё году примерно в 92-м. Вот же ж тупой и упрямый народ эти программисты: долбишь им долбишь, рассказываешь, как им удобнее, — нет, всё блин по-своему делают.

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

ВП>Да, можно. Для этого надо решительно отобрать эту работу у постороннего человека (программиста, потому что он не в курсе дела) и передать ее компетентному человеку, то есть инженеру.

ВП>Почему? Потому что первоисточником знаний является инженер. Инженер стоит на высшей ступени знаний. Он знает данный вопрос (как обрабатывать ошибки) намного лучше, чем программист. Программист получает знания от инженера.

ВП> Вероятность того, инженер, автор прибора, сможет «легко забыть» свой собственный прибор на порядок меньше, чем у программиста, который знает прибор с чужих слов.

Да, а ещё можно отобрать работу по лечению у доктора и отдать её больному. Потому что больной гораздо лучше доктора знает, где у него болит, и уж точно не забудет об этой боли, в отличие от доктора, у которого не болит.

Давайте также отберём работу повара у повара и заставим готовить посетителя кафе, потому что повара вечно пересаливают, а посетитель точно знает, сколько соли он любит.

Сколько я имел дело и с инженерами-электронщиками, чьё железо пинал программно, и с бухгалтерами-кладовщиками всякими, и со всеми остальными постановщиками задач, знающими свою область лучше меня — и всегда оказывалось, что моя въедливость в плане обработки нестандартных ситуаций на порядок выше ихней, и это обычно спасало проект. Как раз потому что я не знаю всех ньюансов их предметной области, но зато знаю как писать программы. В отличие от. И когда они мне говорят — "такого не может быть", я этим спецам в своей области тупо не верю, потому что у меня получается не закрытый if без ветки else, и я пишу этот else, которого "не может быть" и который аккурат через 1-2 месяца таки-случается. И любой программист, достаточно долго работавший с экспертами-постановщиками задач, подтвердит, что так оно всегда и происходит.

Каждый должен заниматься своим делом.