[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
conceptually.)
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