Примерами можно было взять html, css в современных браузерах. Любая
"декларативность" скрывает под собой уже проведенную кем-то работу.
Хорошо если кто-то это уже сделал. А когда проект создается с нуля в сжатые сроки вот тут-то мы и сталкиваемся с небесплатностью декларативной парадигмы. Возникает большое желание описать часть системы декларативно. Но это оказывается почти всегда дорогим по времени. И так как реализация предстоит самим, то разработчики входят в дилемму - или долго разрабатывать и отлаживать декларативное описание системы, или плюнуть и быстро заколхозить систему императивно.
Реализовать функционал императивно (по-старинке) чаще оказывается быстрее, предсказуемо и прямолинейнее, нежели чем создать функционал разбирающий декларативное описание системы.
Мысль понятна?
И это еще не все. При эксплуатации хорошо когда все кейсы укладываются в предусмотренное декларативным описанием. Но если это не так, то приходится засучать рукава и дорабатывать декларативную часть программируя зачастую именно императивно :) Про то что бывает если отсутствует возможность как-то доработать, расширить прокрустово ложе декларативности лучше не вспоминать. (Я вот именно что дорабатывал Firebird, SQL сервер в области многомерных SQL запросов).
RxTx (25.12.2021 21:31, просмотров: 242) ответил cheblin на что "первопроходного" можно желать от SQL? А у Rust и Kotlin
огромное отзывчивое, быстро реагирующие на "хотелки" комьюнити.