Кратко — разница в стиле:

Императивный подход (C, JavaScript, …) описывает последовательность шагов: как достичь результата (управление состоянием, циклы, присваивания).Декларативный подход (SQL, Prolog, чистые функциональные / описательные DSL) описывает, что нужно получить: правила, ограничения, отношения; порядок и механизмы выполнения оставляют среде выполнения/оптимизатору.

Когда декларативный подход существенно упрощает задачу
(примеры и мотивировка)

Запросы и агрегации по данным (SQL, Datalog)
Задача: «получить суммы продаж по клиентам за квартал с фильтрами и объединениями таблиц».Почему проще: SQL выражает joins, группировки и фильтры компактно; оптимизатор базы сам строит план выполнения. Императивно пришлось бы писать вложенные циклы, индексацию, временные структуры.Поиск и перебор с возвратом назад (Prolog, логическое программирование)
Задача: поиск путей в графе с условиями, решение логических головоломок, дедуктивные правила.Почему проще: Prolog выражает правила и использует backtracking/унфикация автоматически; не надо вручную реализовывать стек вызовов и восстановление состояний.Ограничения и CSP (constraint solvers, SAT/SMT)
Задача: планирование, расписание, проверки целостности при ограничениях.Почему проще: описываете ограничения, решатель подбирает модель; вручную — сложный перебор/алгоритмы ветвей и границ.Декларативные шаблоны/конфигурации (Terraform, Kubernetes YAML, CSS, SQL миграции)
Задача: описать желаемое состояние инфраструктуры или стиль.Почему проще: система заботится о порядке операций, idempotence, откате; код читаем и декларативен.Трансформации данных и компиляторы (правила переписывания, регулярные выражения, yacc/PEG)
Задача: распарсить/преобразовать код/строку.Почему проще: формальные грамматики/правила выражают структуру лучше, чем парсинг «вручную».Ревактивные интерфейсы и UI (React — декларативное описание UI)
Задача: описать интерфейс, синхронизующийся с состоянием.Почему проще: описываете, как UI должен выглядеть при состоянии, фреймворк оптимизирует обновления.

Ограничения декларативных языков при моделировании побочных эффектов

Побочные эффекты нарушают предпосылку «описания результата без порядка». Когда важен порядок (I/O, взаимодействие с сетью, датчики, транзакции), декларативная модель должна явно ввести семантику эффектов.Трудности с управлением ресурсами: открытие/закрытие файлов, блокировки, управление памятью и временем жизни — требует явной стратегии (контексты, RAII, finally).Неочевидность последовательности: оптимизатор может переставить операции (например, SQL может менять порядок joins), что мешает, если операции не-коммутативны или имеют побочные эффекты.Отладка и трейсинг: когда среда выполняет правила и делает много оптимизаций/переборов, становится сложнее понять, где и почему произошёл конкретный побочный эффект.Эргономика: пакет сторонних побочных операций в чисто декларативном языке часто выглядит громоздко — нужны примочки (монды в Haskell, effect systems, явные транзакционные блоки).Семантические ограничения: некоторые декларативные формы (чистые функции, логические правила) не позволяют естественно выразить состояние с историей (встроенные изменения), поэтому приходится моделировать состояние как дополнительный аргумент и получать громоздкую модель.

Как декларативные языки решают побочные эффекты (приёмы, примеры)

Явные абстракции эффектов: монады (Haskell — IO), effect handlers, линейные/императивные ссылки (ST в Haskell) — дают контроль, но усложняют модель.Контексты/транзакции: SQL транзакции — позволяют группировать побочные операции в атомарную единицу.Императивные примитивы внутри декларативной среды: stored procedures, внешние функции (UDF), FFI — выносить «горячие» побочные операции в императивный код.Ограничение эффектов в границах: декларативная спецификация для чистых частей, имплементация эффектов в специально помеченных блоках.

Ограничения декларативных языков в отношении производительности

Плюсы: высокоуровневость даёт возможность оптимизации (планировщик SQL, индексирование, мемоизация, дедуктивная оптимизация). В задачах с большими данными декларат. исполнение часто быстрее, чем «тупой» императивный код, потому что среда использует индексы, параллелизм и оптимальные планы.Минусы:
Потеря контроля: сложно гарантировать конкретный порядок выполнения, что критично для оптимизаций низкого уровня (кэш, locality).Непредсказуемость затрат: оптимизатор может выбрать плохой план для редких распределений данных; нужна статистика/подсказки.Накладные расходы: поиск, backtracking, интерпретация правил и создание многих промежуточных структур может быть дорогим по памяти и CPU.Отсутствие in-place обновлений: в чисто функциональных моделях много копирований, если не применяются оптимизации (структурный sharing). Для больших структур это может быть медленнее.Ограниченная контроль над параллелизмом и размещением работы: декларативные среды часто сами параллелят, но специфические схемы распараллеливания/векторизации на уровне инструкций — нет.Встраиваемый низкоуровневый код (например SIMD, ручная аллок.) трудно выразить декларативно; приходится переходить на императив/низкоуровневые библиотеки.

Практические рекомендации

Используйте декларативный стиль там, где домен — запросы, правила, ограничения, трансформации, конфигурация и высокоуровневая логика. Это сокращает код, облегчает сопровождение и даёт оптимизации «за бесплатно».Для операций с явными побочными эффектами, низкоуровневой оптимизации, real-time и управления ресурсами — используйте императивные подходы или гибридный подход (декларация + FFI/императивные компоненты).Если нужен контроль производительности, комбинируйте: профилируйте, вытаскивайте «горячие» участки в императивные оптимизированные реализации, используйте подсказки/индексы/статистику для оптимизатора.Рассмотрите языки/системы, которые дают лучшее из обоих миров: чистые функции + явно маркированные эффекты (Haskell), реактивные декларации поверх императивных колбеков (React), Datalog + внешние функции для побочных эффектов.

Краткое резюме

Декларативные языки великолепны, когда задача — описать отношения, правила, ограничения или желаемое состояние: код становится короче, выразительнее и часто быстрее за счёт оптимизатора.Ограничения появляются, когда нужны детерминированные побочные эффекты, тонкий контроль над ресурсами или микрооптимизация — тогда декларативность либо усложняет моделирование, либо влечёт производственные затраты; решение — явное отделение чистой логики и эффектных/горячих участков, либо использование гибридных подходов.