Re[40]: Axum: паралельное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 17:20
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


T>>>>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns).

G>>>>Вне контекста pattern-matching такое рассматривать смысла нет.

T>>>Этого я не понял. Объясни, пожалуйста.

G>>
G>>int func(int a)
G>>{
G>>  if(a = 1) return 0;
G>>  return 1;
G>>}
G>>

G>>Если последний return не написать то даже компилироваться не будет.
G>>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.

К>Это не особенность записи функций хаскеля, это свойство паттерн-матчинга.

Я вроде тоже самое сказал, но thesz не понял.

К>Ближайшим (правда ооочень фиговым) шарповским аналогом ПМ по-моему является switch, но вот что-то я не припомню проверки полноты его компилятором

К>Можно ещё и про "проваливающиеся" case вспомнить...
А оно там и не надою switch не является выражением, поэтому там такая проверка не требуется.

Если далеко не ходить и взять F#, там тоже есть p-m, там код не компилится при неполных паттернах. Если функция должна падать при некоторых входных данных то жто надо явно указать.
Re[37]: Axum: паралельное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 17:28
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>>>>>Данная "декларативность" его имхо затрудняет.

G>>>>Данная декларативность не влияет на наблюдаемое поведение.
G>>>Она влияет на поведение программы.
G>>Как?

G>Если оно не никак не влиет на поведение программы, то что может заставить программиста писать asynchronous?

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

Using asynchronous methods is often over-kill and has a performance penalty for small methods and functions which do not do I/O or messaging. Therefore, the rule is that methods are synchronous and have to be explicitly identified as asynchronous. The only methods that are asynchronous by default are agent constructors.



G>Я задал вопрос, чем это лучше явного употребления фьючерса. Если это на самом деле работает как фьючерс, то оно влияет на поведение программы, как фьючерс, вставленный в автоматическом режиме. Ты на вопрос не ответил ("декларативностью" — это не ответ). Если оно работает как-то по другому, и я неправильно понимаю — так объясни мне, как оно работает.

Банально заменяет все блокирующие вызовы на неблокирующие (компилятор генерирует "автоматный" код, вместо линейного).

G>Мне то ты зачем этот вопрос задаешь?

Затем и задаю, что ты не разобравшись как оно работает стал выдумывать недостатки.
Re[40]: Axum: паралельное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 17:31
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


G>>int func(int a)

G>>{
G>> if(a = 1) return 0;
G>> return 1;
G>>}
G>>[/ccode]
G>>Если последний return не написать то даже компилироваться не будет.
VE>Во-первых, в Си++ будет. Но, видимо, речь не о нём.
неужели в С++ все так плохо?

VE>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения.

VE>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
Re[41]: Axum: паралельное программирование
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.05.09 17:44
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


G>>>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.


К>>Это не особенность записи функций хаскеля, это свойство паттерн-матчинга.

G>Я вроде тоже самое сказал, но thesz не понял.

Я специально написал, что это не про запись, а ты меня не понял, чтож о Сергее-то говорить?
Re[41]: Axum: паралельное программирование
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.05.09 17:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


VE>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения.

VE>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?

Ты уже определись, то хорошо, что "если не написать, то даже компилироваться не будет", то пофиг, что код станет "код станет неправльным\неполным при добавлении новых значений енума". А то такое впечатление, что ты меняешь мнение в зависимости от выгодности в конкретный момент
Re[42]: Axum: паралельное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 18:15
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


VE>>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения.

VE>>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
G>>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?

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


Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.
Re[41]: Axum: паралельное программирование
От: VoidEx  
Дата: 19.05.09 18:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?

Этого — никто не говорит.
А вот компилятор, который молча компилирует потенциально сделанный неверным код — говорит "а, добавление пару енумов точно ничего не сломает".
Не компилятору это решать, поэтому он обязан сообщить мне о местах, на которые мои изменения могли потенциально повлиять.
Re[43]: Axum: паралельное программирование
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.05.09 20:14
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


G>Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.


Т.е. ты просто до ПМ докопался (не проверямого на полноту по умолчанию в хаскеле), а на остальное пофигу?
Странно, а я думал, в этой ветке про возможную полезность проверок на уровне типов говорили, а оказывается я глубоко заблуждался
Чтот я большего конструктива ждал...
Re[18]: Axum: паралельное программирование
От: Gaperton http://gaperton.livejournal.com
Дата: 20.05.09 07:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если честно, я фиг его знает, что именно делают в прикладном коде эти агенты и какие конкретно там сценарии, за все сценарии не распишусь. Мне, например, и без агентов иногда код как автомат приходится делать, ибо природа задач бывает такова сама по себе, что разворот на C# через yield лишь усложняет или даже вынуждает использовать goto.


Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример:
http://rsdn.ru/forum/message/3392818.1.aspx
Автор: Gaperton
Дата: 17.05.09


V>В общем, вот давняя картинка, попробуй здесь без goto:


V>


Эта увлекательная дискуссия закончилась еще в 70-х годах. Думаю, не надо напоминать, чем?

Это хорошо выглядит на картинке, и отвратительно — в коде.

V> Как, кстати, обстоят дела с интеропом в Эрланге?


Есть байндинги в Java, C/C++, CORBA. Есть, в конце концов, сокеты .
Re[19]: Axum: паралельное программирование
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.09 08:15
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример:

G>http://rsdn.ru/forum/message/3392818.1.aspx
Автор: Gaperton
Дата: 17.05.09


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Axum: паралельное программирование
От: Gaperton http://gaperton.livejournal.com
Дата: 20.05.09 08:26
Оценка:
Здравствуйте, eao197, Вы писали:

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


G>>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример:

G>>http://rsdn.ru/forum/message/3392818.1.aspx
Автор: Gaperton
Дата: 17.05.09


E>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.


Это _не_ мой код. Это пример как будет выглядеть простая проблема в асинхронной записи. У тебя это будет выглядеть еще страшнее, кстати.

И я не вижу ни единой причины, почему мне не стоит приводить это в пример. У тебя асинхронная запись? Да. Все. Хочешь сказать, что я неправ — приведи решение данной проблемы "в своем фреймворке".

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


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

E> Очевидно, что они решались бы сильно по другому. Но не факт, что сложнее файберной магии. Которая, вообще-то говоря, далеко не везде доступна.


Покажи — как по другому. Еще раз — я говорю о простейших сценариях. Под которые, как ты говоришь, фреймворк не заточен? Да нафига он вообще нужен тогда?
Re[20]: Axum: паралельное программирование
От: Gaperton http://gaperton.livejournal.com
Дата: 20.05.09 08:32
Оценка:
Здравствуйте, eao197, Вы писали:

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


G>>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример:

G>>http://rsdn.ru/forum/message/3392818.1.aspx
Автор: Gaperton
Дата: 17.05.09


E>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.


Кстати, просим-просим — запиши этот геморрой на своем фреймворке, вот с этими самыми конечными автоматами, которые ты показывал выше, и приведи код в студию. Пусть люди увидят, на что это будет похоже. Паржом.
Re[41]: Axum: паралельное программирование
От: thesz Россия http://thesz.livejournal.com
Дата: 20.05.09 08:32
Оценка:
VE>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения.
VE>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?

Если это может случиться, то это случится.

Поэтому код станет неправильным/неверным при добавлении новых значений в enum.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: Axum: паралельное программирование
От: thesz Россия http://thesz.livejournal.com
Дата: 20.05.09 08:34
Оценка: +2
G>Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.

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

Сравнение с образцом здесь только инструмент.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Axum: паралельное программирование
От: Gaperton http://gaperton.livejournal.com
Дата: 20.05.09 08:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

E>>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.


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


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

Давай, момент истины — show me the code, хватит уже языками чесать. Убеди меня, что у тебя все не так — покажи красивый, правильный MFC-style код, пестрящий макросами, и вспухший на ровном месте. Вот спорим, ты мне сейчас под каким-либо предлогом не станешь приводить код?

Начнешь опять говорить, что "это не тот случай, под который разрабатывался фреймворк, задача мол слишком простая" — а вот давай будем честными, и покажем, во что превращается самая простая задача в твоем фреймворке. Это и есть его недостаток, понимаешь? Ну вот согласись, признай как оно есть — "да, недостаток". Не надо тебе ни в чем оправдываться, ты это в 97 году рисовал.
Re[19]: Axum: паралельное программирование
От: Курилка Россия http://kirya.narod.ru/
Дата: 20.05.09 09:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


V>>В общем, вот давняя картинка, попробуй здесь без goto:


V>>


G>Эта увлекательная дискуссия закончилась еще в 70-х годах. Думаю, не надо напоминать, чем?


G>Это хорошо выглядит на картинке, и отвратительно — в коде.


Не знаю, по-моему оно и на картинке выглядит извратно аля "кручу верчу — запутать хочу!"
Re[21]: Axum: паралельное программирование
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.09 10:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>И я не вижу ни единой причины, почему мне не стоит приводить это в пример. У тебя асинхронная запись? Да. Все. Хочешь сказать, что я неправ — приведи решение данной проблемы "в своем фреймворке".


Что значит "асинхронная запись"?
Где описание проблемы, которую нужно решить? Пока были только общие слова про какую-то обработку каких-то рядов.

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


Вот пример агента из задачи, которой я занимаюсь прямо сейчас. Этот агент является менеджером дочерних процессов (в каждом из которых сидят собственные агенты-исполнители). Его задачей является получение двух типов запросов (phase_c и phase_p), передача этих запросов в подходящие дочерние процессы, получение ответов от дочерних процессов (phase_c_result, phase_p_result), преобразование ответов в нужный формат, контроль за работоспособностью и наличию связи с дочерними процессами, поддержание актуальной оперативной мониторинговой информации о текущем состоянии. Информация о запросах/результатах, а также уведомления о проблемах с дочерними процессами приходит асинхронно, в произвольном порядке. Контроль состояния и обновление мониторинговой информации нужно делать по таймеру. В принципе, это простейший сценарий для тех задач, которыми я занимаюсь.

Суммарный объем кода одного этого агента -- 1500 физических строк (включая комментарии и пустые строки).
Суммарный объем кода нескольких классов, использующихся данным агентом -- более 2500 физических строк.
Объем кода, связанный с описанием агента для SO: 70 строк макросов + 50 строк подписки на разные сообщения. Т.е. на 4K строк, отвечающих за решение конкретной задачи, приходится 120 строк SO-оверхеда. Вот само описание агента для SO на макросах. Для знакомого с SO разработчика это описание уже раскрывает основную схему работы данного агента.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Axum: паралельное программирование
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.09 10:39
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>С Эрлангом мы конкурировать собрались


Почему бы и нет?

G>Ну вот согласись, признай как оно есть — "да, недостаток".


О том, что многословность -- это недостаток SO4 было публично сказано еще в прошлом году.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Axum: паралельное программирование
От: Gaperton http://gaperton.livejournal.com
Дата: 20.05.09 10:50
Оценка:
Здравствуйте, eao197, Вы писали:

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


G>>С Эрлангом мы конкурировать собрались


E>Почему бы и нет?


Ну, наверное потому, что для того, чтобы всерьез конкурировать, одного желания недостаточно, надо иметь какие-то объективные преимущества. И кроме этого, иметь поменьше недостатков. Или просто — пробелов.

G>>Ну вот согласись, признай как оно есть — "да, недостаток".


E>О том, что многословность -- это недостаток SO4 было публично сказано еще в прошлом году.


"И повторять это я не собираюсь!!!" Так? "Многословность" — это симптом. Причиной является то, что ты назвал в дискуссии со мной "глобальная асинхронность". Не изменив подход к проблеме, ничего радикально исправить нельзя.

Это очень серьезный недостаток в сравнении с Эрлангом. Да и с любым фреймворком, в котором есть легкие потоки. На нем сравнение можно оставить. Все.
Re[24]: Axum: паралельное программирование
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.09 11:25
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Глобальная асинхронность и многословность в C++ -- это, имхо, две ортогональные друг другу вещи.

G>Не изменив подход к проблеме, ничего радикально исправить нельзя.


Я не вижу проблемы там, где ты говоришь. Если что-то делается слишком сложно с помощью SO, то просто не нужно делать это с помощью SO. Кому это нужно, пусть берет любой фреймворк с легкими потоками или пишет свой собственный. SO вовсе не обязан поддерживать разные формы взаимодействия сущностей в приложении. Пусть он делает хорошо то, для чего был предназначен.

G>Да и с любым фреймворком, в котором есть легкие потоки. На нем сравнение можно оставить. Все.


Аминь.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.