[TYPES] Declarative vs imperative

[Uday S Reddy]

Chung-chieh Shan writes:

> I once defined "declarative programming" as "the division of _what_
> to do and _how_ to do it into two modules that can be built and
> reused separately."  

Sorry, I don't buy it.  The distinction of what vs how, i.e., external
behaviour vs internal implementation, exists for *every* software system
implemented in *every* conceivable programming language.  I don't see what
this has to do with being "declarative".

> > Incidentally, Landin rejected the term "declarative" in 1966:
> >   http://dl.acm.org/citation.cfm?id=365257
> > and proposed "denotative" as a better description.  At the time of his
> > writing, imperative programming languages were not "denotative", i.e., no
> > denotational semantics was known for them.  Strachey fixed that problem soon
> > afterwards.
> 
> I take `imperative programming languages were not "denotative"'
> above to mean `imperative programming languages were not known to be
> "denotative"'.  Even if a language has a denotational semantics, those
> denotations might not be what we want to use the language for in the
> "real world".  So Strachey didn't fix Landin's problem except if you
> work on domain-specific languages in the specific domain of partial
> orders.

I was taught programming when I was a second year undergrad, using Dijkstra
& Wirth-style top-down design and stepwise refinement.  So, I always thought
of imperative programming in "denotative" terms.  What vs how were always
clear in my mind.  I probably saw Landin's paper in the months and years
that followed (as I looked through every CACM paper on programming languages
from the 60's and 70's), and probably didn't understand the point of it.
The distinction between denotative and procedural languages that Landin
makes would have seemed to me to be a false dichotomy.  It is perfectly
feasible for something to be "procedural" as well as "denotative".  So, what
is he talking about?

After maturing, I have learnt that many people really have a big mental
block about thinking of things as being procedural as well as denotative.
Simon Peyton Jones seems to have finally conquered this brain space by
explaining the things belonging to the IO types as "actions".  That seems to
make sense to people.  Three cheers to him!

And, let us not get carried away with "real world" ideas.  The "real world"
has been using imperatives for millennia before we got into the game.  We
didn't invent imperatives.  I believe Vijay was talking about a particular
class of users and a particular class of applications where a declarative
interface is the right layer of abstraction.  If he were to talk about a
stock trading system or an on-board flight control system, the right layer
of abstraction could very well be an imperative one.  There is nothing
"unreal world" about imperatives (or "actions" as Simon calls them).

Cheers,
Uday


PS You were probably confusing Strachey with Dana Scott.  Strachey worked on
the semantics of imperative programs.  Scott worked on the semantics of
recursion, using partial orders (and he also collaborated with Strachey on
semantics of imperative programs).  A good place to read about Strachey's
semantics is the book by Mike Gordon, a classic book that I also happened to
read as an undergrad.  It is easy to find used copies of it these days
because a lot of stupid libraries around the world are getting rid of their
copies.

http://www.amazon.co.uk/The-Denotational-Description-Programming-Languages/dp/0387904336/ref=sr_1_1?ie=UTF8&qid=1366406702&sr=8-1&keywords=gordon+denotational+description