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

N>>Если те же самые гарантии присутствовали бы для комбинации {процесс, номер очереди}
SD>Задача как раз состояла в том, чтобы очередь осталась одна. Как только очередей становится много, это полностью меняет сложность языка и работы с ним.

Верно, происходит существенное упрощение в сложных ситуациях — за счёт незначительного усложнения в простых.

SD> Таково мнение OTP board, и я с ним согласен.

Жаль.

N>>Я именно такое и описываю.

SD>Нет, не такое. Ты про множественные mailbox'ы. Я обсуждал это направление много-много раз, но, действительно, эта фича ведет к резкому росту сложности (как реализации receive, так и когнитивной нагрузке при написании кода таких процессов).

Никакого резкого роста сложности нет.
Уже в простейшем варианте, когда из всех очередей по кругу выбираются сообщения, соответствующие шаблону, без приоритетов, но отправка сообщений происходит согласно ожидаемым очередям — например: 0 для обычных info, cast и прочих по умолчанию, 8 для ответов на gen_call, 9 для всяких 'EXIT' — усложнения нет, а избавление от нерегулируемых заторов — есть.
Дальше уже можно думать о приоритетах, выборе из одной очереди и т.п. — но даже такой старт уже решил бы обсуждаемую проблему. "Когнитивные проблемы" типа необходимости выбирать только из конкретной очереди или двух, пока синхронно ждёшь ответ на запрос — это для младшей группы ясель. Или OTP Team и представляет собой именно такую? Иногда создаётся таки впечатление...

N>>Вот потому я и говорю, что когда Erlang был на естественном пике интереса — надо было не изображать из себя царей горы, а слушать, что пользователи просят.
SD>Эрланг никогда не был на "пике естественного интереса". Рекомендую послушать доклады с конференций, "откуда вообще взялся Эрланг". Это был исключительно внутренний проект компании Ericsson, для того, чтобы создавать надежные системы для (тогда) телефонии.

Это не имеет никакой связи с вопросом. В период приблизительно 2005-2012 к нему был интерес сильно выше этого, надо было им пользоваться.

SD>В 13 я уже написал целый графический редактор под винду. Почти Paint. И сделал я это на компьютерах в школе и в мореходке (Мурманск, эта мореходка потом была была переименована в МГАРФ, Мурманская Государственная Академия Рыбопромыслового Флота, и потом — в МГТУ, Мурманский Государственный Технический Университет). А лет с 8 или 9 я вовсю пилил программы на калькуляторе МК-61 (том самом, который от розетки работал, но мог и от батареек, только недолго). Польскую нотацию я с тех пор и помню. "Положить в стек 2, положить в стек 4, вызвать операцию суммирования". Круть

Ну у меня как-то похоже, но на пару лет позже по возрасту. Спасибо за рассказ

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

N>>Если те же самые гарантии присутствовали бы для комбинации {процесс, номер очереди}
SD>Задача как раз состояла в том, чтобы очередь осталась одна. Как только очередей становится много, это полностью меняет сложность языка и работы с ним.

Верно, происходит существенное упрощение в сложных ситуациях — за счёт незначительного усложнения в простых.

SD> Таково мнение OTP board, и я с ним согласен.

Жаль.

N>>Я именно такое и описываю.

SD>Нет, не такое. Ты про множественные mailbox'ы. Я обсуждал это направление много-много раз, но, действительно, эта фича ведет к резкому росту сложности (как реализации receive, так и когнитивной нагрузке при написании кода таких процессов).

Никакого резкого роста сложности нет.
Уже в простейшем варианте, когда из всех очередей по кругу выбираются сообщения, соответствующие шаблону, без приоритетов, но отправка сообщений происходит согласно ожидаемым очередям — например: 0 для обычных info, cast и прочих по умолчанию, 8 для ответов на gen_call, 9 для всяких 'EXIT' — усложнения нет, а избавление от нерегулируемых заторов — есть.
Дальше уже можно думать о приоритетах, выборе из одной очереди и т.п. — но даже такой старт уже решил бы обсуждаемую проблему. "Когнитивные проблемы" типа необходимости выбирать только из конкретной очереди или двух, пока синхронно ждёшь ответ на запрос — это для младшей группы ясель. Или OTP Board и представляет собой именно такую? Иногда создаётся таки впечатление...

N>>Вот потому я и говорю, что когда Erlang был на естественном пике интереса — надо было не изображать из себя царей горы, а слушать, что пользователи просят.
SD>Эрланг никогда не был на "пике естественного интереса". Рекомендую послушать доклады с конференций, "откуда вообще взялся Эрланг". Это был исключительно внутренний проект компании Ericsson, для того, чтобы создавать надежные системы для (тогда) телефонии.

Это не имеет никакой связи с вопросом. В период приблизительно 2005-2012 к нему был интерес сильно выше этого, надо было им пользоваться.

SD>В 13 я уже написал целый графический редактор под винду. Почти Paint. И сделал я это на компьютерах в школе и в мореходке (Мурманск, эта мореходка потом была была переименована в МГАРФ, Мурманская Государственная Академия Рыбопромыслового Флота, и потом — в МГТУ, Мурманский Государственный Технический Университет). А лет с 8 или 9 я вовсю пилил программы на калькуляторе МК-61 (том самом, который от розетки работал, но мог и от батареек, только недолго). Польскую нотацию я с тех пор и помню. "Положить в стек 2, положить в стек 4, вызвать операцию суммирования". Круть

Ну у меня как-то похоже, но на пару лет позже по возрасту. Спасибо за рассказ