Здравствуйте, alex_public, Вы писали:
_>Т.е. то, что я написал код вида
_>

_>for(;;){
_>    Analyze(rand());
_>    this_thread::sleep_for(chrono::seconds(1));
_>}
_>

Вы не написали такого кода. Вы написали совсем другой код, в котором никакого Analyze нету, и который построен на разрушающих изменениях локального состояния.

_>абсолютно никак не поменяло обсуждаемую функцию Analyzer.
Пока что никакой функции нету. Есть гипотетическая функция, которая конкурирует в обсуждении с конкретным, уже работающим кодом.

_>2. Если мы всё же говорим, что основной смысл Rx — это реализация паттерна Наблюдатель для коллекций, а не некие последующие linq-подобные извращения, то тогда у меня к Rx нет ни малейших претензий. Ну разве что кроме того, что обычно подобное проще написать самому, чем подключать стороннюю библиотеку.
Rx — это реализация паттерна "произвольные выражения" для цепочек событий.

_>Ну так если нам нужен конечный автомат, то для этого есть отличные специализированные инструменты, причём без всяких ужасов типа попытки записать некое подобие БНФ через linq синтаксис. Т.е. для простейших случаев пишем линейный код, а для сложных берём удобный конечный автомат (например boost.statechart). И это всё находится внутри функции Analyzer, которую опять же можно вызывать и внутри цикла и реактивным способом.
Нам не нужен конечный автомат. Точно так же, как нам не нужен стек для арифметики — удобнее просто писать арифметические выражения в школьной нотации.
Конечный (или бесконечный) автомат — это деталь реализации. А нам нужна возможность записать реакцию на события в понятном виде.
Ваш оппонент просто пытается вам объяснить, что с точки зрения декларативной семантики парсинг активно-читаемого текста и анализ цепочек событий — одно и то же, поэтому рулят системы, которые отделяют запись правил анализа от механизмов получения данных, и даже от активности/пассивности стиля получения данных.
А вы по-прежнему рассказываете про то, что лучше писать всё каждый раз руками, или использовать готовые монолитные библиотеки. Это как если бы фанат С рассказывал, что шаблонные коллекции — это какой-то непонятный механизм, и что ему нетрудно руками написать compare_values(x, y) для каждого нужного ему типа, либо вообще использовать готовую библиотеку, которая сразу умеет читать массивы double из файла и сортировать их оптимальным образом.

Меня вот, к примеру, бесит, что все механизмы по работе с XML, к примеру, построены на DOM модели. Это означает, что я не могу написать эффективный код по потоковому разбору приезжаюшего на сервер потока в реактивном режиме. Точнее, могу — если перейду на SAX парсер и буду всё читать руками. Ничего из готового кода по десериализации, валидации, или XPath работать не будет. Там всё построено на том, что надо активно дрючить Document, который обязан быть готов к моменту начала работы. А я бы хотел иметь всё наоборот — чтобы у меня был реактивный XPath Expression, который выплёвает найденную Node в виде события каждый раз, как только она готова; чтобы он работал поверх SAX-парсера, который запихивает в этот XPath прочитанные элементы в виде событий, и тоже работает поверх "обратного streamreader", который запихивает в парсер читаемый текст по мере готовности. И, естественно, streamreader тоже должен работать "наоборот", т.е. не вызывать stream.Read(), а ждать от реактивного stream события DataArrived.
Всё это можно сделать, вот только
1. объём работы огромен: процитированная иерархия — это чуть менее, чем "до хрена" кода, при этом переписать его в реактивном стиле не вполне тривиально.
2. результат работы — дубирование кода. То есть надо будет править ошибки параллельно в двух реализациях StreamReader, XmlDocument, и XPathExpression.

Хочется обратного: чтобы я написал код в понятном виде. А уже среда/библиотеки/хрен его знает что автоматически сгенерировала хоть активную, хоть реактивную версии.
Вот Rx — это первый известный мне подход к весу.

Он, к сожалению, никак не отвечает на многие конкретные вопросы. В частности, запись правил парсинга на нём далеко не идеальна, хоть и лучше многих альтернативных вариантов. Или, скажем, попытаться написать на нём хотя бы реактивный RegEx я бы не взялся.