[TYPES] Declarative vs imperative

Vijay Saraswat vijay at saraswat.org
Fri Apr 19 02:32:08 EDT 2013

On 4/18/13 5:15 PM, Robert Harper wrote:
> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
> The term "declarative" never meant a damn thing, but was often used, absurdly, to somehow lump together functional programming with logic programming, and separate it from imperative programming.  It never made a lick of sense; it's just a marketing term.
Why would you say this? (I hesitate diving into a forty year old debate, 
but you have such a charming manner, its hard to resist :-))

Declarative means a heck of a lot. (Though I do agree that distinctions 
between function and logic programming are probably not that significant 

Declarative as in having an associated interpretation in terms of 
(probabilistic / first-order / ...) models, and reasoning that is valid 
wrt that interpretation. Declarative as in fundamentally 
representational. Hence understandable / accessible to people who are 
interested only in the real world phenomena that is being modeled (e.g. 
engineers, scientists, business users) and not necessarily how the 
reasoning is realized within modern computational hardware.

Imperative as in focused on efficient representation and manipulation of 
(shared) state.

I can show an HCC program to an engineer and he can see the differential 
equations he loves and understands, and why the query being asked makes 
sense. But there is very little chance he would understand the 
implementation of the reasoning engine (all imperative code). With 
declarative programming, the beauty is he does not need to care. The 
program *is* a fragment of logic and its consequences perfectly 
describable in terms the user recognizes and understands, not in 
implementational terms.

(Or a business user using ILOG JRules to represent decision trees for 
sales promotions... or...)

Yes sub-structural logics complicate the situation, at some level of 
abstraction. But if computer science is about anything it is about 
building layers of abstractions (or "lies" as someone put it), and not 
understanding something solely through reductionism.

More information about the Types-list mailing list