G>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
T>>Ух ты!
T>>В чем отличие от Википедии?
G>Во всем, по той ссылке что ты привел нету ничего похожего.

Ну, так выскажи своё понимание.

А то получается, что ты обладаешь неким секретным знанием, которое позволяет тебе видеть положительное в этих самых dataflows.

T>>>>Это не тот пример, на который стоит обращать внимание.
T>>>>Это всего лишь асинхронность, её даже на плюсах можно сделать.
T>>>>Важно же само программирование — реакция со сложной логикой на разные события.
T>>>>Это упустил из виду eao, это не рассматривают товарищи из Axum.
G>>>А пример можно?
T>>Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом).
T>>Erlang больше, чем сообщения и процессы.
T>>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.

G>Мда.. видно непонимание сути исследвательского проекта.

Не спорю.

Так объясни непонимающему.

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

G>>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
T>>>Ух ты!
T>>>В чем отличие от Википедии?
G>>Во всем, по той ссылке что ты привел нету ничего похожего.
T>Ну, так выскажи своё понимание.
http://ru.wikipedia.org/wiki/Композиция_функций

T>>>>>Это не тот пример, на который стоит обращать внимание.
T>>>>>Это всего лишь асинхронность, её даже на плюсах можно сделать.
T>>>>>Важно же само программирование — реакция со сложной логикой на разные события.
T>>>>>Это упустил из виду eao, это не рассматривают товарищи из Axum.
G>>>>А пример можно?
T>>>Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом).
T>>>Erlang больше, чем сообщения и процессы.
T>>>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.

G>>Мда.. видно непонимание сути исследвательского проекта.

T>Не спорю.
T>Так объясни непонимающему.
Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#.

Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.

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

G>Кошмар. Как много буков надо написать, и как много надо знать, просто для того, чтобы сообщения получить. Сложную логику за таким кодом будет не разобрать.

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

А уж если брать микропримеры, то Hello, World на C++ гораздо многословнее, чем на Ruby. Но на таком сравнении бессмыслено делать заключения о возможностях C++.

G>Вопрос — ты когда эти ферймворки выдумываешь, какой-нибудь полезный код на них пробуешь писать?

Да.

G>Можешь пример прикладного кода привести для иллюстрации?

Вот, например, описание агента. Более-менее сложного.

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

G>>Кошмар. Как много буков надо написать, и как много надо знать, просто для того, чтобы сообщения получить. Сложную логику за таким кодом будет не разобрать.

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

Я довольно неплохо знаком на практике как со "статически типизированными языками", так и с многолюдными, длительными проектами. И с С++ тоже.

Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.

E>А уж если брать микропримеры, то Hello, World на C++ гораздо многословнее, чем на Ruby. Но на таком сравнении бессмыслено делать заключения о возможностях C++.

Я не говорю о микропримерах. Это в твоей статье кроме них ничего нет.

G>>Можешь пример прикладного кода привести для иллюстрации?

E>Вот, например, описание агента. Более-менее сложного.

Концы. И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.

Плохо.

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

G>Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.

Нравится, не нравится -- это все субъективные критерии. Мне, например, код на Erlang-е и ScalaActors не нравится. Поскольку, имхо, там очень важные вещи размазанны по коду. Тем не менее, кому-то именно такой стиль нравится больше.

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

G>И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.

Да, в этом и была цель в то время. Очень простое решение. Как в реализации, так и в освоении.

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

G>>Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.

E>Нравится, не нравится -- это все субъективные критерии. Мне, например, код на Erlang-е и ScalaActors не нравится. Поскольку, имхо, там очень важные вещи размазанны по коду. Тем не менее, кому-то именно такой стиль нравится больше.

Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.

E>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.

Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и писать синхронно. А вот подход Эрланга позволяет обрабатывать сотни тысяч нитей простого синхронного кода. И все так же без каких-либо проблем синхронизации — это вообще свойство модели коммуникации параллельных процессов.

G>>И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.

E>Да, в этом и была цель в то время. Очень простое решение. Как в реализации, так и в освоении.

Ну, раз именно такой и была цель, то ты ее вне всяких сомнений достиг. Тока MFC-style сам по себе не лучшее решение. Он не полагается на возможности С++ "правильным" образом.

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

G>Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и [позволяет] писать синхронно.

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

G>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.

Это слова.

E>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.

G>Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и писать синхронно. А вот подход Эрланга позволяет обрабатывать сотни тысяч нитей простого синхронного кода. И все так же без каких-либо проблем синхронизации — это вообще свойство модели коммуникации параллельных процессов.

Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?

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

G>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.

E>Это слова.

Это у тебя — слова.

E>>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.

E>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?

О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?

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

G>>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.

E>>Это слова.

G>Это у тебя — слова.

Ну конечно.

E>>>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.

E>>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?

G>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?

То, что он тебе не нравится, это уже понятно.

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

E>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?

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

Смотри. Вот это — асинхронный код. На "псевдокоде" пишу.

do_something()
{
   m_service.request_something();
   m_service.subscribe_for_request_completion_event( this );
}

request_completed()
{
   use( m_service.get_result() );
}

А вот это — соответствующий синхронный код.

do_something()
{
     use( m_service.request_something() );
}

Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.

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

А разница между стилями ровно в одном. Как ты получаешь сообщение — синхронным блокирующим вызовом, или же ты вынужден вернуть управление наверх и получить коллбэк.

Это — самая существенная, фундаментальная разница, и Эрланг здесь собственно не причем. Хотя, его придумали люди, очень тонко и грубоко понимающие реальные проблемы построения больших систем, и он выглядит так, как выглядит, далеко не просто так. Скажем, подумай на досуге немного о том, почему и зачем в Эрланге сделан селективный receive на одном мэйлбоксе, а не по другому. Hint — это решение сильно упрощает код в реальных программах.

G>>>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
T>>>>Ух ты!
T>>>>В чем отличие от Википедии?
G>>>Во всем, по той ссылке что ты привел нету ничего похожего.
T>>Ну, так выскажи своё понимание.
G>http://ru.wikipedia.org/wiki/Композиция_функций

Я так и думал.

T>>Не спорю.
T>>Так объясни непонимающему.
G>Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#.
G>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.

И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?

Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения.

А все подхватили.

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

G>>>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.

E>>>Это слова.

G>>Это у тебя — слова.

E>Ну конечно.

Конечно.

G>>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?

E>То, что он тебе не нравится, это уже понятно.

Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.

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

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

Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.

G>А вот это — соответствующий синхронный код.

G>

G>do_something()
G>{
G>     use( m_service.request_something() );
G>}
G>

G>Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.

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

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

Простые -- да, будут. Сложные, напротив, становятся более читабельными и наглядными.

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

E>>>>Это слова.

G>>>Это у тебя — слова.

E>>Ну конечно.

G>Конечно.

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

G>>>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?

E>>То, что он тебе не нравится, это уже понятно.

G>Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.

Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.

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

E>>>>>Это слова.

G>>>>Это у тебя — слова.

E>>>Ну конечно.

G>>Конечно.

E>Ну вот и состоялся обстоятельный обмен неоспоримыми доказательствами.

Ты ожидал чего-то другого на фразу "это слова"?

G>>Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.

E>Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.

Я, вообще-то, этого не говорил.

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

E>>Ну вот и состоялся обстоятельный обмен неоспоримыми доказательствами.

G>Ты ожидал чего-то другого на фразу "это слова"?

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

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

E>>Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.

G>Я, вообще-то, этого не говорил.

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

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

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

E>Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.

Ну, это же thesz сказал. Пусть он за это и отдувается, так? Я конечно понимаю, что у нас на RSDN споры традиционно командные, и кровавое мочилово обычно идет стенка на стенку, но вроде бы, оно еще не началось, нет?

G>>А вот это — соответствующий синхронный код.

G>>

G>>do_something()
G>>{
G>>     use( m_service.request_something() );
G>>}
G>>

G>>Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.

E>Этот сценарий идет лесом в ситуациях, когда во время ожидания результата request_something нужно обработать еще парочку-другую входящих запросов.

Да, это простейший сценарий, но именно он наиболее распространен в случае "протокольных" задач, например. Однако, давай действительно его оставим, и рассмотрим твой.

Когда возникает такая необходимость, у тебя есть два варианта.
1) Разбить одного агента на два (подставь нужное число), где все приведется к синхронному случаю.
2) Использовать стиль "wait_for_multiple_ojects". То есть, ты блокируешься в одном вызове, ожидая любого из перечисленных событий.

В предельном случае (2) разумеется сведется к явному конечному автомату. Однако, он все равно будет гораздо проще, потому, что простые случаи ты обработаешь синхронно. Плюс ко всему, даже в этом случае у тебя во многих ситуациях сохранится возможность записывать автомат неявно, с "состоянием" в локальных переменных.

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

E>Простые -- да, будут. Сложные, напротив, становятся более читабельными и наглядными.

Понимаешь, в чем дело. Во-первых, не хочется, чтобы простые случаи затуманивали на ровном месте код, вызывая у читателя шок и трепет. Раз они простые — почему бы им и не выглядеть просто.

А для сложного случая — что мне мешает сделать по месту и необходимости message loop и использовать твой стиль (кстати, во многих случаях я этого смогу избежать, расщепив агента на несколько)? Получается, что я могу комбинировать оба подхода, а ты привязан к одному из них. Хорошо ли это?

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

T>>>Не спорю.
T>>>Так объясни непонимающему.
G>>Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#.
G>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.

T>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?
Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.

T>Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения.
Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.

T>А все подхватили.
Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда.

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

E>>Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.

G>Ну, это же thesz сказал. Пусть он за это и отдувается, так?

Хорошо.

G>Когда возникает такая необходимость, у тебя есть два варианта.
G>1) Разбить одного агента на два (подставь нужное число), где все приведется к синхронному случаю.

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

G>2) Использовать стиль "wait_for_multiple_ojects". То есть, ты блокируешься в одном вызове, ожидая любого из перечисленных событий.

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

G>Понимаешь, в чем дело. Во-первых, не хочется, чтобы простые случаи затуманивали на ровном месте код, вызывая у читателя шок и трепет. Раз они простые — почему бы им и не выглядеть просто.

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

G>А для сложного случая — что мне мешает сделать по месту и необходимости message loop и использовать твой стиль (кстати, во многих случаях я этого смогу избежать, расщепив агента на несколько)?

Одной из целей было освобождение разработчика от необходимости взаимодействия с message loop вообще. И, как следствие, от избавления от спагети-кода, в который, как правило, превращается при сопровождении работа с message loop.

G>Получается, что я могу комбинировать оба подхода, а ты привязан к одному из них. Хорошо ли это?

Мне кажется, что тотальная асинхронность все-таки лучше тотальной синхронности.