Я нажал сохранять локально

Да, спасибо

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

TLDR: стримы и FRP это не те технологии, которые можно сравнивать.

Стримы — это абстракция позволяющая создавать итеративное, объединяемое вычисление с контролем за памятью (все свойства важны). Они предоставляют интефейс и отвечают за выполение одного вычисления. То, с чем можно так или иначе сравнить стримы: ленивое IO, fusion. Существует несколько разных реализацией стримов, отличающихся лишь внешним API, но у всех общая модель и абстракция, одни переводятся в другие zero-cost преобразованием.

FRP — принцип построения взаимодействий в системе основанный на реакции на изменение других компонент (тут специально слишком абстрактно, чтобы не вдаваться в классы RFP). Важные свойства: удобство описания эволюции программы. Т.е. оно отвечает за полнопрограмное взаимодействие. Альтернативы с которыми сравнивать: actor model, разные системы подписок. FRP — это более высокоуровневая абстракция. Существует много разных концепцией FRP не имеющих в своей модели ничего общего, одну систему нельзя конвертировать в другую.

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

Может ли FRP решить задачи стримов? — нет не может. С помощью FRP систем (существующих на данный момент) не выразить итеративный (это можно), объединяемый (тут спорно, но в самых продвинутых моделях, возникает общие события и состояние, поэтому одни компоненты знают про другие), и эффективный (использование памяти и state leak очень частая проблема в FRP) процесс. А главное, непонятно зачем, учитывая, что FRP объединяет несколько точек взаимодействия, а мы редуцируем его до одной. В целом выражение низкоуровневых моделей через высокоуровневые приводит к протеканию абстракций и боли на пустом месте.

Итого:
1. Стримы и FRP это абстрации разных уровней
1.1. Stream — низкоуровневая модель для процесса
1.2 FRP — нечеткая принцип моделирования для всей программы

Стримы и FRP это не те концепции, которые можно противоставлять, а которые нужно сопоставлять:
1. stream-model можно встроить в любую RFP модель комбинаторами вроде sourceEvent, sinkEvent аналогичными sourceTBQueue. sinkTBQueue, которые  вчера написали.
2. с помощью набора stream можно выразить взаимодействующую сеть компонент, но тогда эту штуку можно назвать одной из принципа RFP.
3. В RFP можно легко обойтись без стримов, если нет источников событий, в которых нужно контролировать их выполнение. Или всё завязано на общий стейт, как в Elm-like фреймворках

чот многобукаф 🙁

TLDR; есть - можно не волноваться)

https://www.youtube.com/watch?v=ECO0GJPw8Bo&feature=youtu.be ссылка на видео к слову

Отлично, уже видео!

@heyley а мое видео утеряно?

Я думаю, что нет, но если я понимаю правильно, то у Лейлы сейчас не все прекрасно с интернетом (и докладом по LHCb)

У меня видео записывал и загружал я, поэтому смог сразу

И поэтому сделал это криво, без первых n минут и вступления

Я ещё предлагал, чтобы кто-нибудь про азы хаскеля рассказал, а то два видео, и там уровень плавает от среднего до средне-продвинутого

Мне кажется - это будет актуально

@astynax ^

Либо, мне кажется, @dshevchenko может круто рассказать

В группе, где обучаются хаскелю с нуля, очень любят его книгу за манеру подачи

Рад слышать

Если вдруг будет желание рассказать - я в этой группе скажу) Явка будет больше обычного

чем ты запускаешь вот такие комментарии? -- $>

ghcid