Декларативное программирование - паттерн ограничения семантики.

Все эти "что VS как" часто оторваны от реальности. В действительности, какая-то синтаксическая конструкция может включать в себя много семантики, имея большой контекст работы, а может мало.

Семантика, что? Не очень понятно? Когда мы пишем код - мы решаем с помощью него какую-то задачу. Проблема мейнстримных ЯП в том что в нескольких строчках их кода может содержаться много смысла и то что этот же смысл может быть записан другими строчками кода. Массив в JS можно обойти с помощью ключевых конструкций for, for of, for in и while, встроенного метода forEach или вспомогательной библиотеки, вроде R.forEach. При этом, в циклах можно использовать break и continue, а в колбеках forEach никакого break, только early return. await внутри вычисления дает разное поведение в колбеках и в цикле. Крыша уже едет, а мы просто хотели посмотреть на элементы массива.

Чем больше способов у нас есть для решения одной и той же задачи - тем проще нам будет ее решить при возникновении дополнительных условий. Но зачем ориентироваться на крайние случаи, когда в большинстве своем мы пишем однообразный код?

Под декларативным программированием обычно понимают использование таких конструкций, которые будут однозначны. Код с таким свойством действительно прост, легко пишется, легко читается и понимается. Это самое важное, на что стоит обращать внимание.

Какие есть еще способы достичь однозначности?

DSL (Domain Specific Language) - отдельный язык для описания очень ограниченного набора задач - в рамках выбранного домена. Т.к. он должен решать небольшой набор задач, то и код на нем проще и однозначнее. Причем, не обязательно такой код будет декларативен.

Бывают примеры, когда декларативный DSL оказывается чрезмерно сложным и позволяет одну задачу решать разными способами.
SQL прекрасный и, казалось бы, декларативный язык. Андрей рассказывал о его сравнении с наивной реализацией на общем языке программирования. Но как только вам нужна частая выгрузка для аналитики и перф, начинается профилирование сложности и пляски с джоинами (привет императив) вплоть до перестроения схемы. А по другому все еще не научились, оптимизация SQL до сих пор насущный вопрос.

Я бы забанил слово "декларативный" в наших комьюнити, потому что смысл оно только размазывает, а не подчеркивает. Это базворд, который считают за безусловное благо, хотя оно таковым не является.

Код должен быть однозначным - в этом заключается простота. Если глядя на код, не зная о входящих данных, можно с уверенностью сказать что он делает - это простой и однозначный код. Проектируйте API ваших библиотек с этой мыслью.