Паттернт Observer и ЯП

Я хотел поговорить о функциональщине и сопутствующих альтернативах паттерну Observer.

Есть статья Одерски, где пишется, что Observer устарел (смотреть тута). Слышал предложение в качестве альтернативы использовать Functional reactive programming. Оно уже достаточно популярно, даже в богомерзком JS используется.

Для хацкеля есть давно зарекомендовавший себя reactive-banana, мне же больше импонирует reflex. Пока ни один не проверял в деле.

Let's battle Observer vs FRP begin!

Прогуглил я это дело — все как я и думал, observer можно замутить везде, даже без ООП на ФП, лишь бы была возможность реализации стека/массива.

Для хаскеля гуглится только протухший проект https://github.com/gimbo/observer.hs , что как бы намекает.

Тег «haskell» добавь, пожалуйста.

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

Предположим, что сомнительность обсервера нас не волнует, но мы готовы радоваться чему угодно похожему. Для этого есть общий ответ FRP: библиотеки netwire (arrow FRP), reactive-banana (behavior driven development),вроде либа Гонсалеса и пост про table driven development, который как раз таки почти обсервер и наиболее просто. Авторы вышеперечисленных либ написали немало работ, по поводу FRP, которые достаточно легко читаются.

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

Сравнивать ФП и ООП не надо.

ООП - о разделении ответственности.

ФП противопостовляется императивщине.

«Если в вашем коде используются паттерны проектирования значит он имеет недостато высокий уровень абстракции»

В ФП Observer банально не нужен, не надо его там реализовывать.

Если в вашем коде используются паттерны проектирования значит он имеет недостато высокий уровень абстракции

Откуда цитата?

Paul Graham. Правда, он немного другими словами сказал, но суть одна.

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

Да, было бы интересно почитать, и ссылки нужны.

библиотеки netwire (arrow FRP)

Как я успел начитаться, построение FRP на основе arrow или applicative — это сложно, особенно для новичков, а каких-то преимуществ над behavior-driven решениями оно не дает.

Ссылок хотелось бы, а то я вопросом не очень владею.

Тем не менее скажу что мне всегда не нравился обсервер как решение.

Его дебажить вообще как? Когда в системе куча событий, твой код начинает жить своей жизнью, — мне от этого как-то неуютно.

Вобщем мне всегда хотелось «цепочечного» апи. FRP же?

Да. Есть решения для JS --> http://habrahabr.ru/post/198656/

Соглашусь с утверждением, что arrow для новичков сложно, но в applicative ничего сложного нету.

Я встречал на /r/haskell мнение, что Arrow появился в языке во времена, когда Applicative не было, и что с появлением Applicative нужна в Arrow в большинстве случаев отпала.

Можно реализовать, но ненужно. Смотри на ФРП.

Построение (то есть реализация библиотек) действительно сложно, есть довольно много нюансов и сложно get it right. Но пользоваться грамотно реализованной библиотекой не сложно.

Мне нравится то, как сделано в F# (псевдокод, потому как уже не помню точно):

type IObservable<'a> with
  member Await : IObservable<'a> -> Async<'a>

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

Потом, IObservable<'a> по сути является моноидом. Такие значения можно соединять. Для них определено нулевое значение относительно операции соединения. Потом, их можно трансформировать, т.е. IObservable - это еще и функтор. IObservable - это то, чем могли бы быть события в функциональном языке программирования.

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

Такой же однострочник:

processAwait :: Signal a -> Process a

Все написанное про моноиды и функтор остается справедливым относительно типа Signal.

http://conal.net/papers/push-pull-frp/ И вообще другие статьи Конала, так Heinrich Apfelmus - автор reactive-banana, и невыговариваемого Ertugrul Söylemez (автор netwire).

Вообще наверное можно начать с обзора http://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf

http://www.haskellforall.com/2014/06/spreadsheet-like-programming-in-haskell.... а вот это ближе к таковому обсерверу и тут видно, как в хацкелях такое выглядит.