Кратенько.

[thesz]

Сперва дам два определения. Они не точные, не претендуют на истину, просто для пояснения, что же я имею в виду

Comments

[wizzard0]

> параллелизм позволяет легко совмещать фреймворки.
Очень верно подмечено.

Кстати, а вы пробовали приспосабливать к этому делу Rx? А то у меня никак руки не дойдут.

Вообще да, жаль что никак Axum до ума не доведут, парадигма акторов и\или потоков данных все более и более актуальна.

[thesz]

>Кстати, а вы пробовали приспосабливать к этому делу Rx? А то у меня никак руки не дойдут.

Автор всего этого чуда vshabanov пишет на Хаскеле и достаточно прагматичен, чтобы не использовать лишнего. ;)

[wizzard0]

Ну, мне Rx навеяло фразой "Осталось только посетовать на отсутствие в C# каналов а-ля Chan/TChan Хаскеля"

А так - да, согласен))

[nivanych]

> Фреймворк - это когда
> пользовательский код
> вызывается по наступлению
> некоторых условий.

Скажем так, это каким-то образом сформулированная некая логика (может быть, что и совсем простая), и вдобавок, некоторые разрешаторы этой логики.

[thesz]

Здесь важно противоположное направление управления.

[nivanych]

То есть, от использования тех, "низкоуровневых" библиотек...
Ну, даже и в этом случае, сказанное мною тоже вполне возможно.

[monocalibro]

а у нас Бобруйске в PostGre все сразу -- и пользовательские скрипты внутри, вызываемые по условию/событию. И пользовательский код вполне себе управляет SQL запросами. С параллелизмом не совсем хорошо, но решаемо.
Может дело не в имманентных парадоксах, а в правильной архитектуре?

[migmit]

> Я подумал, что параллелизм позволяет легко совмещать фреймворки.

Континуэйшенов должно хватить.

[swizard]

> Континуэйшенов должно хватить.

Все правильно, я про это писал статью в ПФП :)

[thesz]

Даже если два фреймворка событийно-ориентированные?

[swizard]

Да никаких проблем, хоть три.