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

Примерами декларативных языков программирования являются SQL и Prolog.

Это метод программирования, основанный на описании какие того, что должно делать или должно быть, вместо описания как, которое должно работать.

Другими словами, вы не пишете алгоритмы, состоящие из выражений, вы просто делаете макет так, как вы хотите, чтобы все было. Два хороших примера - это HTML и WPF.

Эта статья в Википедии представляет собой хороший обзор: http://en.wikipedia.org/wiki/Declarative_programming

Декларативное программирование - это картина, а императивное программирование - это инструкции по рисованию этой картинки.

Вы пишете в декларативном стиле, если вы «говорите, что это такое», а не описываете шаги, которые компьютер должен предпринять, чтобы добраться туда, куда вы хотите.

Когда вы используете XML для разметки данных, вы используете декларативное программирование, потому что вы говорите: «Это человек, у него день рождения, а вон там почтовый адрес».

Некоторые примеры того, как декларативное и императивное программирование объединяется для большего эффекта:

• Windows Presentation Foundation использует декларативный синтаксис XML для описания того, как выглядит пользовательский интерфейс, и каковы отношения (привязки) между элементами управления и базовыми структурами данных.

• В структурированных файлах конфигурации используется декларативный синтаксис (такой простой, как пары «ключ = значение») для определения значения строки или значения данных.

• HTML помечает текст тегами, описывающими роль каждого фрагмента текста по отношению ко всему документу.

Еще пара примеров декларативного программирования:

• Разметка ASP.Net для привязки данных. Он просто говорит, например, «заполните эту сетку этим источником», и оставляет систему на усмотрение, как это происходит.
• Выражения Linq

Декларативное программирование - это хорошо, потому что оно может помочь упростите свою ментальную модель * кода и потому, что со временем оно может быть более масштабируемым.

Например, предположим, что у вас есть функция, которая что-то делает с каждым элементом в массиве или списке. Традиционный код выглядел бы так:

foreach (object item in MyList)
{
   DoSomething(item);
}

Ничего страшного. Но что, если вы воспользуетесь более декларативным синтаксисом и вместо этого определите DoSomething () как действие? Тогда вы можете сказать это так:

MyList.ForEach(DoSometing);

Это, конечно, более лаконично. Но я уверен, что у вас больше проблем, чем просто сохранить две строчки кода здесь и там. Например, производительность. При старом методе обработку приходилось производить последовательно. Что, если бы у метода .ForEach () был способ сообщить вам, что он может обрабатывать параллельную обработку автоматически? Вы внезапно сделали свой код многопоточным и изменили только одну строку кода. Фактически, существует расширение для .Net, который позволяет вам это делать.

• Если вы перейдете по этой ссылке, то попадете на запись в блоге моего друга. Весь пост получился длинноватым, но вы можете прокрутить вниз до заголовка с названием "The Problem" _и забрать его там без проблем. *

Описывать компьютеру то, что вы хотите, а не как что-то делать.

Насколько я могу судить, его начали использовать для описания систем программирования, таких как Пролог, потому что Пролог (предположительно) предназначен для абстрактного объявления вещей.

Это все больше и больше значит очень мало, так как имеет определение, данное вышеупомянутыми пользователями. Должно быть ясно, что существует пропасть между декларативным программированием Haskell и декларативным программированием HTML.

представьте себе страницу Excel. С столбцами, заполненными формулами для расчета налоговой декларации.

Вся логика объявлена ​​в ячейках, порядок вычислений определяется самой формулой, а не процедурно.

Вот что такое декларативное программирование. Вы объявляете пространство проблемы и решение, а не ход программы.

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

Другие ответы уже отлично объясняют, что такое декларативное программирование, поэтому я просто приведу несколько примеров того, почему это может быть полезно.

Независимость от контекста

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

Возьмем, к примеру, yacc. Это генератор парсеров, он же. компилятор компилятора, внешний декларативный DSL для описания грамматики языка, так что синтаксический анализатор для этого языка может быть автоматически сгенерирован из описания. Из-за независимости от контекста с такой грамматикой можно делать много разных вещей:

• Создайте синтаксический анализатор C для этой грамматики (исходный вариант использования yacc)
• Создайте синтаксический анализатор C++ для этой грамматики
• Создайте синтаксический анализатор Java для этой грамматики (используя Jay)
• Создайте синтаксический анализатор C# для этой грамматики (используя GPPG)
• Создайте синтаксический анализатор Ruby для этой грамматики (используя Racc)
• Создайте визуализацию дерева для этой грамматики (используя GraphViz)
• просто сделайте красивую печать, причудливое форматирование и выделение синтаксиса самого исходного файла yacc и включите его в свое справочное руководство в качестве синтаксической спецификации вашего языка

И многое другое…

Оптимизация

Поскольку вы не предписываете компьютеру, какие шаги и в каком порядке выполнять, он может гораздо более свободно изменять вашу программу, возможно, даже выполнять некоторые задачи параллельно. Хороший пример - планировщик запросов и оптимизатор запросов для базы данных SQL. Большинство баз данных SQL позволяют отображать запросы, которые они выполняют на самом деле, по сравнению с запросами, которые вы выполняете с помощью спросил. Часто эти запросы выглядят как ничего такого, как друг друга. Планировщик запросов принимает во внимание вещи, о которых вы даже не мечтали: задержку вращения диска, например, или тот факт, что какое-то совершенно другое приложение для совершенно другого пользователя просто выполнило аналогичный запрос и таблицу, в которой вы находитесь. присоединение и то, что вы так усердно работали, чтобы избежать загрузки, в любом случае уже находится в памяти.

Здесь есть интересный компромисс: машине приходится работать усерднее, чтобы вычислить как, чтобы что-то делать, чем на императивном языке, но когда делает понимает это, у нее гораздо больше свободы и гораздо больше информации для оптимизации. сцена.

Я бы объяснил это, поскольку DP - это способ выразить

• A выражение цели, условия для - то, что мы ищем. Есть один, может быть или много?
• Некоторые известные факты
• Правила, расширяющие известные факты

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

Это может показаться странным, но я бы добавил Excel (или любую другую таблицу) в список декларативных систем. Хороший пример этого - здесь.

Мне очень жаль, но я не согласен со многими другими ответами. Я хотел бы остановить это путанное непонимание определения декларативного программирования.

Определение

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

Другие упомянутые атрибуты декларативного программирования происходят из этого RT. Пожалуйста, щелкните гиперссылку выше для получения подробного объяснения.

Пример таблицы

В двух ответах упоминалось программирование электронных таблиц. В тех случаях, когда программирование электронных таблиц (также известных как формулы) не имеет доступа к изменяемому состоянию Глобальный, тогда это декларативное программирование. Это связано с тем, что изменяемые значения ячеек представляют собой монолитные Вход и выходmain() (всей программы). Новые значения не записываются в ячейки после выполнения каждой формулы, поэтому они не изменяются в течение срока действия декларативной программы (выполнение всех формул в электронной таблице). Таким образом, относительно друг друга формулы рассматривают эти изменяемые ячейки как неизменяемые. Функции RT разрешен доступ к глобальному состоянию неизменный (а также изменяемое состояние местный).

Таким образом, возможность изменять значения в ячейках при завершении программы (как результат main()) не делает их изменяемыми сохраненными значениями в контексте правил. Ключевым отличием является то, что значения ячеек не обновляются после выполнения каждой формулы электронной таблицы, поэтому порядок выполнения формул не имеет значения. Значения ячеек обновляются после выполнения всех декларативных формул.

Я улучшил свое понимание декларативного программирования с декабря 2011 года, когда я ответил на этот вопрос ответ. Здесь следует мое текущее понимание.

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

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

В самом наивном и крайнем смысле (который я утверждал в своем предыдущем ответе) декларативное программирование (DP) избегает всего хранимого изменяемого состояния, поэтому упорядочение и / или дублирование программных инструкций может НЕТ изменить поведение (семантику) программы. .

Однако такое крайнее определение было бы не очень полезным в реальном мире, поскольку почти каждая программа включает хранимое изменяемое состояние. пример таблицы соответствует этому крайнему определению DP, потому что весь программный код выполняется до завершения с одной статической копией входного состояния, прежде чем новые состояния будут сохранены. Затем, если какое-либо состояние изменяется, это повторяется. Но большинство реальных программ не могут ограничиваться такой монолитной моделью изменений состояния.

Более полезное определение DP состоит в том, что упорядочение и / или дублирование инструкций программирования не изменяет непрозрачную семантику. Другими словами, в семантике не происходит скрытых случайных изменений - любые изменения в порядке команд программы и / или дублирование вызывают только запланированные и прозрачные изменения в поведении программы.

Следующим шагом будет обсуждение того, какие модели программирования или парадигмы помогают в DP, но вопрос не в этом.

Декларативное программирование - это «акт программирования на языках, которые соответствуют ментальной модели разработчика, а не операционной модели машины».

Разница между декларативным и императивным программированием хорошо проиллюстрирован проблемой синтаксического анализа структурированных данных.

Императивная программа будет использовать взаимно рекурсивные функции для потребления ввода. и генерировать данные. Декларативная программа выражает грамматику, определяющую структура данных для последующего анализа.

Разница между этими двумя подходами в том, что декларативная программа создает новый язык, который более точно соответствует ментальной модели проблема, чем его основной язык.

Свободно:

Декларативное программирование имеет тенденцию к:

• Наборы деклараций или декларативных операторов, каждое из которых имеет значение (часто в проблемной области) и может пониматься независимо и изолированно.

Императивное программирование имеет тенденцию к:

• Последовательности команд, каждая из которых выполняет какое-либо действие; но которые могут иметь или не иметь значение в проблемной области.

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

В реальных программах (даже если они написаны на языках, ориентированных на конечные точки спектра, таких как ProLog или C), как правило, оба стиля присутствуют в разной степени в разных точках, чтобы удовлетворить различные сложности и коммуникационные потребности произведения. Один стиль не превосходит другой; они просто служат разным целям, и, как и во многих других вещах в жизни, умеренность является ключевым моментом.

Декларативное программирование - это программирование с объявлениями, то есть декларативными предложениями. Декларативные предложения обладают рядом свойств, которые отличают их от повелительных предложений. В частности, декларациями являются:

• коммутативный (можно переупорядочивать)
• ассоциативный (можно перегруппировать)
• идемпотент (может повторяться без изменения значения)
• монотонный (объявления не вычитают информацию)

Важным моментом является то, что все это структурные свойства и ортогональны предмету. Декларативная - это не про "Что и как". Мы можем объявить (представить и ограничить) "как" так же легко, как мы объявляем "какие". Декларативная - это структура, а не содержание. Декларативное программирование оказывает значительное влияние на то, как мы абстрагируем и реорганизуем наш код, и как мы модулируем его в подпрограммы, но не столько на модель предметной области.

Часто мы можем перейти от императивного к декларативному, добавив контекст. Например. от «Поверните налево. (... подождите ...) Поверните направо». на «Боб повернет налево на пересечении улиц Foo и Bar в 11:01. Боб повернет направо на пересечении Bar и Baz в 11:06». Обратите внимание, что в последнем случае предложения идемпотентны и коммутативны, тогда как в первом случае перестановка или повторение предложений сильно изменит смысл программы.

Что касается монотонный, объявления могут добавлять ограничения, который вычитает возможности. Но ограничения по-прежнему добавляют информацию (точнее, ограничения - это информация). Если нам нужны изменяющиеся во времени объявления, это типично моделировать с явной временной семантикой - например, от «мяч плоский» до «мяч плоский в момент времени T». Если у нас есть два противоречащих друг другу объявления, у нас есть противоречивая декларативная система, хотя это можно решить, введя ограничения мягкий (приоритеты, вероятности и т. д.) Или используя паранепротиворечивую логику.

Поскольку я написал свой предыдущий ответ, я сформулировал новое определение декларативного свойства, которое цитируется ниже. Я также определил императивное программирование как двойственное свойство.

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

Цитируемое объяснение определения обсуждает роль, которую функциональное программирование чистый играет в декларативном программировании.

Declarative vs. Imperative

The declarative property is weird, obtuse, and difficult to capture in a technically precise definition that remains general and not ambiguous, because it is a naive notion that we can declare the meaning (a.k.a semantics) of the program without incurring unintended side effects. There is an inherent tension between expression of meaning and avoidance of unintended effects, and this tension actually derives from the incompleteness theorems of programming and our universe.

It is oversimplification, technically imprecise, and often ambiguous to define declarative as “what to do” and imperative as “how to do”. An ambiguous case is the “what” is the “how” in a program that outputs a program— a compiler.

Evidently the unbounded recursion that makes a language Turing complete, is also analogously in the semantics— not only in the syntactical structure of evaluation (a.k.a. operational semantics). This is logically an example analogous to Gödel's theorem— “any complete system of axioms is also inconsistent”. Ponder the contradictory weirdness of that quote! It is also an example that demonstrates how the expression of semantics does not have a provable bound, thus we can't prove2 that a program (and analogously its semantics) halt a.k.a. the Halting theorem.

The incompleteness theorems derive from the fundamental nature of our universe, which as stated in the Second Law of Thermodynamics is “the entropy (a.k.a. the # of independent possibilities) is trending to maximum forever”. The coding and design of a program is never finished— it's alive!— because it attempts to address a real world need, and the semantics of the real world are always changing and trending to more possibilities. Humans never stop discovering new things (including errors in programs ;-).

To precisely and technically capture this aforementioned desired notion within this weird universe that has no edge (ponder that! there is no “outside” of our universe), requires a terse but deceptively-not-simple definition which will sound incorrect until it is explained deeply.

Definition:

---

The declarative property is where there can exist only one possible set of statements that can express each specific modular semantic.

The imperative property3 is the dual, where semantics are inconsistent under composition and/or can be expressed with variations of sets of statements.

---

This definition of declarative is distinctively local in semantic scope, meaning that it requires that a modular semantic maintain its consistent meaning regardless where and how it's instantiated and employed in global scope. Thus each declarative modular semantic should be intrinsically orthogonal to all possible others— and not an impossible (due to incompleteness theorems) global algorithm or model for witnessing consistency, which is also the point of “More Is Not Always Better” by Robert Harper, Professor of Computer Science at Carnegie Mellon University, one of the designers of Standard ML.

Examples of these modular declarative semantics include category theory functors e.g. the Applicative, nominal typing, namespaces, named fields, and w.r.t. to operational level of semantics then pure functional programming.

Thus well designed declarative languages can more clearly express meaning, albeit with some loss of generality in what can be expressed, yet a gain in what can be expressed with intrinsic consistency.

An example of the aforementioned definition is the set of formulas in the cells of a spreadsheet program— which are not expected to give the same meaning when moved to different column and row cells, i.e. cell identifiers changed. The cell identifiers are part of and not superfluous to the intended meaning. So each spreadsheet result is unique w.r.t. to the cell identifiers in a set of formulas. The consistent modular semantic in this case is use of cell identifiers as the input and output of pure functions for cells formulas (see below).

Hyper Text Markup Language a.k.a. HTML— the language for static web pages— is an example of a highly (but not perfectly3) declarative language that (at least before HTML 5) had no capability to express dynamic behavior. HTML is perhaps the easiest language to learn. For dynamic behavior, an imperative scripting language such as JavaScript was usually combined with HTML. HTML without JavaScript fits the declarative definition because each nominal type (i.e. the tags) maintains its consistent meaning under composition within the rules of the syntax.

A competing definition for declarative is the commutative and idempotent properties of the semantic statements, i.e. that statements can be reordered and duplicated without changing the meaning. For example, statements assigning values to named fields can be reordered and duplicated without changed the meaning of the program, if those names are modular w.r.t. to any implied order. Names sometimes imply an order, e.g. cell identifiers include their column and row position— moving a total on spreadsheet changes its meaning. Otherwise, these properties implicitly require global consistency of semantics. It is generally impossible to design the semantics of statements so they remain consistent if randomly ordered or duplicated, because order and duplication are intrinsic to semantics. For example, the statements “Foo exists” (or construction) and “Foo does not exist” (and destruction). If one considers random inconsistency endemical of the intended semantics, then one accepts this definition as general enough for the declarative property. In essence this definition is vacuous as a generalized definition because it attempts to make consistency orthogonal to semantics, i.e. to defy the fact that the universe of semantics is dynamically unbounded and can't be captured in a global coherence paradigm.

Requiring the commutative and idempotent properties for the (structural evaluation order of the) lower-level operational semantics converts operational semantics to a declarative localized modular semantic, e.g. pure functional programming (including recursion instead of imperative loops). Then the operational order of the implementation details do not impact (i.e. spread globally into) the consistency of the higher-level semantics. For example, the order of evaluation of (and theoretically also the duplication of) the spreadsheet formulas doesn't matter because the outputs are not copied to the inputs until after all outputs have been computed, i.e. analogous to pure functions.

C, Java, C++, C#, PHP, and JavaScript aren't particularly declarative. Copute's syntax and Python's syntax are more declaratively coupled to intended results, i.e. consistent syntactical semantics that eliminate the extraneous so one can readily comprehend code after they've forgotten it. Copute and Haskell enforce determinism of the operational semantics and encourage “don't repeat yourself” (DRY), because they only allow the pure functional paradigm.

---

2 Even where we can prove the semantics of a program, e.g. with the language Coq, this is limited to the semantics that are expressed in the typing, and typing can never capture all of the semantics of a program— not even for languages that are not Turing complete, e.g. with HTML+CSS it is possible to express inconsistent combinations which thus have undefined semantics.

3 Many explanations incorrectly claim that only imperative programming has syntactically ordered statements. I clarified this confusion between imperative and functional programming. For example, the order of HTML statements does not reduce the consistency of their meaning.

Обновлено: я разместил следующий комментарий в блоге Роберта Харпера:

in functional programming ... the range of variation of a variable is a type

Depending on how one distinguishes functional from imperative programming, your ‘assignable’ in an imperative program also may have a type placing a bound on its variability.

The only non-muddled definition I currently appreciate for functional programming is a) functions as first-class objects and types, b) preference for recursion over loops, and/or c) pure functions— i.e. those functions which do not impact the desired semantics of the program when memoized (_{^{thus perfectly pure functional programming doesn't exist in a general purpose denotational semantics due to impacts of operational semantics, e.g. memory allocation}}).

The idempotent property of a pure function means the function call on its variables can be substituted by its value, which is not generally the case for the arguments of an imperative procedure. Pure functions seem to be declarative w.r.t. to the uncomposed state transitions between the input and result types.

But the composition of pure functions does not maintain any such consistency, because it is possible to model a side-effect (global state) imperative process in a pure functional programming language, e.g. Haskell's IOMonad and moreover it is entirely impossible to prevent doing such in any Turing complete pure functional programming language.

As I wrote in 2012 which seems to the similar consensus of comments in your recent blog, that declarative programming is an attempt to capture the notion that the intended semantics are never opaque. Examples of opaque semantics are dependence on order, dependence on erasure of higher-level semantics at the operational semantics layer (e.g. casts are not conversions and reified generics limit higher-level semantics), and dependence on variable values which can not be checked (proved correct) by the programming language.

Thus I have concluded that only non-Turing complete languages can be declarative.

Thus one unambiguous and distinct attribute of a declarative language could be that its output can be proven to obey some enumerable set of generative rules. For example, for any specific HTML program (ignoring differences in the ways interpreters diverge) that is not scripted (i.e. is not Turing complete) then its output variability can be enumerable. Or more succinctly an HTML program is a pure function of its variability. Ditto a spreadsheet program is a pure function of its input variables.

So it seems to me that declarative languages are the antithesis of unbounded recursion, i.e. per Gödel's second incompleteness theorem self-referential theorems can't be proven.

Lesie Lamport wrote a fairytale about how Euclid might have worked around Gödel's incompleteness theorems applied to math proofs in the programming language context by to congruence between types and logic (Curry-Howard correspondence, etc).

Это зависит от того, как вы отправите ответ на текст. В целом вы можете смотреть на программу под определенным углом, но это зависит от того, под каким углом вы смотрите на проблему. Я помогу вам начать работу с программой: Тусклый автобус, автомобиль, время, высота как интегр.

Опять же, это зависит от общей проблемы. Возможно, вам придется сократить его из-за программы. Надеюсь, это поможет, и если это не так, нужна обратная связь. Спасибо.

Вот пример.

В CSS (используемом для стилизации HTML-страниц), если вы хотите, чтобы элемент изображения был 100 пикселей в высоту и 100 пикселей в ширину, вы просто «объявляете», что хотите, следующим образом:

#myImageId {
height: 100px;
width: 100px;
}

Вы можете рассматривать CSS как декларативный язык «таблиц стилей».

Движок браузера, который читает и интерпретирует этот CSS, может сделать изображение таким высоким и таким широким, как захочет. Различные движки браузера (например, движок IE, движок Chrome) будут реализовывать эту задачу по-разному.

Их уникальные реализации, конечно, написаны НЕ на декларативном языке, а на процедурном языке, таком как Assembly, C, C++, Java, JavaScript или Python. Этот код представляет собой набор шагов, которые нужно выполнять пошагово (и может включать вызовы функций). Он может делать такие вещи, как интерполяция значений пикселей и рендеринг на экране.