ну я, мягко говоря, не гуру эрланга и фп, но могу сказать, что чистое stateless фп (как и любая парадигма, религия и т.д.) идеально применимо к решению сферических задач в вакууме, а не реальных-полезных на практике, такие дела.
как обычно, нужно комбинировать…
дело в том, что эрланг дает нам out-of-the-box удобности типа легких потоков, эффективного ipc, распределение между ярдами, компами, динамика среды, упрощение построения протоколов, слежение за процессами и т.д., все остальное лежит на девелопере, от этого никуда не деться )
магическое избавление от стейта это такой хитрый маркетинг, ну типа как ооп.
никакая парадигма не избавляет от того, что нужно как-то решать конкурентный доступ к данным не теряя сильно в производительности и предсказуемости.
дотнетом вообще не владею.
это оно? it.toolbox.com/blogs/coding-dotnet/innerexception-14200
если я правильно понял, то это хранения одного эксепшена в другом, что можно вполне организовать и на пхп.
только не запутывание кода ли это? если есть, например, 3 уровня, 1й ловит второй, а 2й — 3й, и каждый перебрасывает свой эксепшн, то 1й уровень о 3м знать не должен, а то банально инкапсуляция нарушается
>перебрасывает его с помощью throw
еще надо отметить, что перебрасывать надо именно само исключение, а то некоторые говнокодят catch (Exception $e) {throw new Exception($e->getMessage());}
>То есть опросить все процессы?
нет, опросить «справочник», но мы просто разделяем его на несколько частей-процессов, которые и опрашиваем, и он перестает быть узким.
т.е. например: есть два процесса, в каждом по половине справочника. посылаем им запросы, они *параллельно* проверяют у себя аккаунт, и дальше уже по-разному можно. отвечает нашедший справочник или уже сам процесс-аккаунт и т.д.
тут получается узкое место — один процесс, хранящий все аккаунты. мне кажется, лучше делать просто рассылку запроса процессам, отвечающим за аккаунты, и ответит нужный процесс. т.е. мы можем разбить список аккаунтов на несколько процессов (на кластер например), которые будут уже контролировать сами процессы-аккаунты.
как-то так
ожидал, что не изменится, и он не изменился )
>dict — это не хранилище, а просто переменная с гибкой структурой, такая же как и все остальные в Эрланге
ага
>у каждого процесса будет свой реестр банковских счетов
это уже зависит от архитектуры приложения. мы же не будем гонять по процессам весь реестр, он большой, храниться он будет в бд…
конечно, нельзя допустить чтобы у процессов были разные конфликтующие данные…
ну почему масса, я вижу реальную проблему только с этим.
проблема дизайна, да, но, судя по всему, эта проблема на данный момент вообще не имеет нормального решения.
ну будут те же локи, зато остальное удобно масштабировать и т.д.
эрланг не лучший язык, но зато можно решать актуальные проблемы без костылей и достаточно стабильно, за нативные микротреды можно многое простить )
по старинке, локами ))
да не, я и говорю, вот и не ясно…
эрланг ведь, как и любой другой язык, не решает эти вопросы, он просто предлагает определенные удобства и формализации. все то же самое можно делать и на stackless python, и на jocaml, и на чем угодно, но стаклесс — костыль, а эрланг приспособлен by design.
а проблема изменения глобальных state'ов пока остается на разработчике в любом случае
я вот тоже пока не понимаю, является ли handle_call «атомарным». перерыл много статей, везде хэлло вордлы, надо видимо писать тесты самому…
а вцелом, сам армстронг, например, предлагает использовать т.н. транзакционнную память armstrongonsoftware.blogspot.com/2006/09/pure-and-simple-transaction-memories.html
но у нее тоже есть свои нехилые заморочки
и пишут о ней весьма разное mags.acm.org/queue/200809/?pg=49
на днях вот пощупал, кстати. весьма интересно, разные языки, благодатная mozilla-платформа, оч быстро работает (автокомплит вообще мгновенный) (сразу чувствуется что написано не на яве ыы), есть актуальные плагины, например поддержка фреймворка js-core меня прямо-таки удивила, и для мутулз есть. не говоря уже о смарти, cakephp, django и т.д.
не пойму, почему она непопулярна. возможность писать плагины на js, казалось бы, должна была дать бум как у firefox. то ли мало пиара, то ли времени еще мало прошло…
еще плохо, что в edit нет поддержки svn-систем и дебаггинга, но это вроде не проблема для разработчиков плагинов
а по сабжу — щас сижу на netbeans тоже, но вот поглядываю в сторону komodo ) потому что потенциал-то по сути побольше будет
как обычно, нужно комбинировать…
дело в том, что эрланг дает нам out-of-the-box удобности типа легких потоков, эффективного ipc, распределение между ярдами, компами, динамика среды, упрощение построения протоколов, слежение за процессами и т.д., все остальное лежит на девелопере, от этого никуда не деться )
магическое избавление от стейта это такой хитрый маркетинг, ну типа как ооп.
никакая парадигма не избавляет от того, что нужно как-то решать конкурентный доступ к данным не теряя сильно в производительности и предсказуемости.
это оно? it.toolbox.com/blogs/coding-dotnet/innerexception-14200
если я правильно понял, то это хранения одного эксепшена в другом, что можно вполне организовать и на пхп.
только не запутывание кода ли это? если есть, например, 3 уровня, 1й ловит второй, а 2й — 3й, и каждый перебрасывает свой эксепшн, то 1й уровень о 3м знать не должен, а то банально инкапсуляция нарушается
еще надо отметить, что перебрасывать надо именно само исключение, а то некоторые говнокодят catch (Exception $e) {throw new Exception($e->getMessage());}
нет, опросить «справочник», но мы просто разделяем его на несколько частей-процессов, которые и опрашиваем, и он перестает быть узким.
т.е. например: есть два процесса, в каждом по половине справочника. посылаем им запросы, они *параллельно* проверяют у себя аккаунт, и дальше уже по-разному можно. отвечает нашедший справочник или уже сам процесс-аккаунт и т.д.
как-то так
что примечательно,
>Currently in use on Youtube (where most of the frontend is Python)
и вообще, это будет эпичная победа
>dict — это не хранилище, а просто переменная с гибкой структурой, такая же как и все остальные в Эрланге
ага
>у каждого процесса будет свой реестр банковских счетов
это уже зависит от архитектуры приложения. мы же не будем гонять по процессам весь реестр, он большой, храниться он будет в бд…
конечно, нельзя допустить чтобы у процессов были разные конфликтующие данные…
проблема дизайна, да, но, судя по всему, эта проблема на данный момент вообще не имеет нормального решения.
ну будут те же локи, зато остальное удобно масштабировать и т.д.
эрланг не лучший язык, но зато можно решать актуальные проблемы без костылей и достаточно стабильно, за нативные микротреды можно многое простить )
да не, я и говорю, вот и не ясно…
эрланг ведь, как и любой другой язык, не решает эти вопросы, он просто предлагает определенные удобства и формализации. все то же самое можно делать и на stackless python, и на jocaml, и на чем угодно, но стаклесс — костыль, а эрланг приспособлен by design.
а проблема изменения глобальных state'ов пока остается на разработчике в любом случае
D = dict:new(),
io:format(«D:~n~p~n», [D]),
D1 = dict:store(«foo», bar, D),
io:format(«D:~n~p~n», [D]),
io:format(«D:~n~p~n», [D1]).
а вцелом, сам армстронг, например, предлагает использовать т.н. транзакционнную память armstrongonsoftware.blogspot.com/2006/09/pure-and-simple-transaction-memories.html
но у нее тоже есть свои нехилые заморочки
и пишут о ней весьма разное mags.acm.org/queue/200809/?pg=49
не пойму, почему она непопулярна. возможность писать плагины на js, казалось бы, должна была дать бум как у firefox. то ли мало пиара, то ли времени еще мало прошло…
еще плохо, что в edit нет поддержки svn-систем и дебаггинга, но это вроде не проблема для разработчиков плагинов
а по сабжу — щас сижу на netbeans тоже, но вот поглядываю в сторону komodo ) потому что потенциал-то по сути побольше будет