Ответ 1
FRP - очень общий метод и почти наверняка может быть использован для реализации всего, что обычно использует события. В классическом исполнении FRP одной из основных абстракций является событие. Разница в том, что вместо того, чтобы работать с событиями индивидуально с обратными вызовами, вы работаете с потоками событий.
Вы должны иметь возможность отображать любой обычный управляемый событиями код в терминах потоков событий; единственная трудность заключалась бы в привязке ваших потоков с существующим внешним кодом, подобным GUI-инструментарию; однако это более утомительно, чем сложно. Поэтому я не вижу принципиальной проблемы, которая мешает вам использовать FRP везде, где вы бы использовали события на другом языке.
На самом деле, у меня был хороший опыт использования FRP для того, что вы называете "легче": простые графические программы. Я использовал реактивный банан с помощью wxWidgets, чтобы написать очень простые маленькие графические программы. Я обнаружил, что полученный код будет намного проще, легче писать и читать легче, чем эквивалентный код на основе обратного вызова.
Reactive Banana также может использоваться для таких вещей, как музыка, поэтому он явно широко применим. Я не пробовал ничего, кроме программирования GUI с ним, но у других есть так, что это должно быть возможно.
Кроме того, вы должны проверить Elm, который является языком стиля ML для реализации веб-приложений с FRP. Он генерирует все, что вам нужно: HTML, CSS и JavaScript. Я считаю, что он даже обрабатывает связь с сервером. Я не пробовал, но выглядит очень хорошо.
Итак, люди явно используют FRP в самых разных областях, включая те, которые не являются "тяжелыми". Но это не значит, что вы должны использовать его везде!
Во-первых, можно получить непредсказуемое пространственное и временное поведение. Я знаю, что создатели Reactive Banana и Elm приложили немало усилий для их сокращения, но я подозреваю, что есть еще некоторый риск. Я знаю, что у меня было очень странное пространство, когда вы играли с Reactive Banana WX, так что, конечно же, что-то нужно искать. С FRP может быть труднее справиться с ними, чем с кодом события, с которым вы привыкли работать. Конечно, у меня были необъяснимые утечки памяти со стандартным JavaScript, поэтому код без FRP не застрахован от этого!
Еще одно соображение заключается в том, что FRP не может быть лучшей или четкой абстракцией для вашей конкретной задачи. Хотя это здорово для вещей, которые должны быть полностью реактивными, что относительно кода, который очень прост, как веб-сервер? (Я имею в виду, что простые, как и в разных запросах, вероятно, не слишком тесно взаимодействуют друг с другом.) Я полагаю, что возможно создание веб-фреймворка, который обрабатывал большое количество запросов с использованием модели программирования на основе FRP; Я просто не думаю, что это было бы оптимально.
Фактически, я понимаю, что система ввода-вывода GHC на самом деле уже управляется событиями под капотом, поэтому вы можете писать веб-серверы в стандартном стиле программирования и получать преимущества использования событий бесплатно. Таким образом, для кода веб-сервера более простая базовая абстракция может быть лучшим выбором. Я считаю, что существующие структуры, такие как Snap и Yesod, не используют стиль реактивного программирования, но оба они по-прежнему приятны в использовании.