
What Is Declarative Programming (2013) - signa11
http://michaelrbernste.in/2013/06/20/what-is-declarative-programming.html
======
lispm
"We say the operation is declarative if, whenever called with the same
arguments, it returns the same results independent of any other computation
state."

That's the use of the term 'declarative programming' by the functional
programming community. There are some other uses of it.

Usually in computer science 'declarative programming' means: the problem is
described and way to the solution is determined from the problem description.
A declarative program describes 'what' and not 'how'. The detailed control
flow is not described.

• specify static properties of problems

* solutions are computed

* no explicit dynamic behaviour

see also:

[http://en.wikipedia.org/wiki/Declarative_programming](http://en.wikipedia.org/wiki/Declarative_programming)

~~~
seanmcdirmid
I've seen "declarative" languages that included if statements (explicit
dynamic behavior!) still passed off as declarative. Some even add sequencing,
and what not. However, its ok because they aren't part of the language core,
just escape hatches on expressiveness :)

"Declarative" always exists in a spectrum: one's specification is another's
implementation. It used to be that Fortran was "declarative" because you no
longer had to write machine code and schedule instructions by hand! In truth,
it is about how many, not just the kind, details can be omitted. E.g. the list
order element is probably important, and if HTML couldn't guarantee that this
order would be preserved at run-time, there would be some big problems.

~~~
innguest
> It used to be that Fortran was "declarative" because you no longer had to
> write machine code and schedule instructions by hand!

Maybe, but even at that time, pure mathematics was still more declarative than
Fortran, so it's not a relative term.

> In truth, it is about how many, not just the kind, details can be omitted.

I think it's about the kind of details that can be omitted. If I can omit
implementation details (how to execute my code on a given machine) from my
function declaration, then that is a declarative function.

~~~
seanmcdirmid
Again, an implementation is just a more detailed specification. I can say
"make me a cake", or I could provide a high level theory on cake baking so my
cake gets made, or a detailed recipe, or I can describe all the movements
needed exactly. Which one is declarative?

There are many levels in describing what one wants, that there is somehow a
magical sharp line where it becomes "how" is not reasonable.

------
lliwta
This blog post points out problems with the three criteria given in the
article for what "declarative" means:
[http://existentialtype.wordpress.com/2013/07/18/what-if-
anyt...](http://existentialtype.wordpress.com/2013/07/18/what-if-anything-is-
a-declarative-language/)

edit: addresses -> points out problems with.

edit2: the blog post also addresses the "referential transparency"
characterization.

------
ww520
Spreadsheet is a declarative programming system with a simple programming
model and an amazingly intuitive UI, that has enabled a generation of non-
programmers to do very complex computation and analysis.

~~~
lliwta
Spreadsheets meet none of the three criteria given in the article:

* Independence: Spreadsheets explicitly rely upon mutable state for <strike>all</strike> some commonly-used operations (i.e., the value of cells).

* Statelessness: Non-independence implies non-statelessness.

* Deterministic: Non-independence implies non-determinism.

The reasoning for the last two point to an underlying problem with the
criteria (removing the word "computation" from independence makes the three
inter-reducible in any real-world machine). but yeah.

edit: all functions->some commonly-used operations

edit wrt downvotes: perhaps reserve judgement unless you've maintained a very
large spreadsheet-based application written by non-programmers. Spreadsheets
-- as most commonly used in practice -- do not meet the criteria above, except
for the smallest/most trivial of applications. Period.

Now, perhaps the problem is the definition. Or perhaps the problem is that
spreadsheets are awful at-scale (even assembly can be quite elegant for small
problems or when usage is well-constrained). Or maybe both.

~~~
ww520
I think you've confused what mutable state is. The cell values entered by a
user are input values. The derived value of a cell bases on the computation of
other cells, which is not changed once computed. When a user changes an input
value in a cell, a new round of computation of the whole spreadsheet is
started. The input value are not mutable state during computation. The modal
of computation of a spreadsheet is pretty much stateless.

The computation between cells are done by the declaring formulas and cell
dependency. The order of computation or how the computation is carried out is
not specified, which is what declarative programming is.

The input cells and derived cells are pretty much like the tables and computed
views in a RDBMS, where SQL is a declarative language to define the view.

~~~
lliwta
> I think you've confused what mutable state is.

Absolutely not.

Macros provide shared mutable state. Macros are used pervasively in
spreadsheet programming. You cannot carte blanc ignore macros without some
serious explanation.

> The modal of computation of a spreadsheet is pretty much stateless.

Relative references means semantics depend on code layout, which in most
hygenic circumstances is an old-school GOTO. In truly awful uses, relative
references recover the sort of code layout dependencies which even C avoids.
This can definitely be _even worse_ than shared mutable state.

------
aikah
> Declarativeness is a property of code which subsumes what professional
> developers typically refer to as functional and purely functional code.
> While real world applications don't allow us to solely rely on declarative
> code to solve all of our problems, we can embrace its positive qualities and
> learn to overcome its shortcomings by following two basic approaches:
> embedding and extending.

I like the balanced conclusion. So as I understand it,languages like
Haskell(which I dont know) wrap states into a type that can be passed to pure
functions right?is that what monads are about? A bit like promises in
javascript where the developpers wraps an eventual outcome into an object and
can reason about his code without worrying about what the value will be or
even if the value will be at all?

More generally,how one does remove side-effects from OO code?since objects are
statefull,or is the solution not using OO at all?

~~~
mp8
> So as I understand it,languages like Haskell(which I dont know) wrap states
> into a type that can be passed to pure functions right?

I would restate this as: "In Haskell you write a description of a stateful
computation." The "State Monad" is really just the illusion of mutable state,
provided by passing the underlying state to each described computation.
Actually-mutable state is possible with things like IORef, but these are
impure.

~~~
mbrock
You could also say it's just an implementation of mutable state. The "State"
type and its operations are just a few lines of simple Haskell code. The
implementation uses parameters and return values to thread state between
functions. It's just a simple abstraction of a simple pattern of programming.
It uses a monadic interface, which is convenient and gives you some syntactic
sugar, but there's nothing magical about it.

From the Haskell point of view, so called "actually-mutable" state is on the
other hand deeply magical, because it lets you do exotic things like having
one thread modify a value in another thread. And that's possible through
things like IORefs. But it should be avoided as much as possible.

~~~
mp8
Really I just wanted to point out that the State Monad is not actually hiding
any "real" mutation anywhere, nor is it related to the IO Monad- I was
confused on this point for some time when learning Haskell.

------
cwhy
CSS should be a very good example...

~~~
adamnemecek
CSS is a markup though and not a Turing complete language.

EDIT: Turns out that HTML5 + CSS3 are in fact accidentally Turing complete
[http://beza1e1.tuxen.de/articles/accidentally_turing_complet...](http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html).
Regardless, it's still only accidentally Turing complete.

