Imperative vs. Declarative

I prefer the imperative style personally, I like things done the way I want ... I kid, great write-up though.

Great article, but one thing that's sort of glossed over here, and that I half-disagree with, is this:

>But we also get to think and operate at a higher level, up in the clouds of what we want to happen, and not down in the dirty of how it should happen.

The author mentions this at the end, but I feel it should be stressed more strongly: The dirty of how is important. The author presents a big "if" here, which is: if the function we've built to abstract away some ugliness performs in the best, most efficient way possible, with no drawbacks, then, yes, abstracting that functionality away and forgetting it is okay.

But to me that's a big if. It is just as important to me to understand and recognize that map is fast, efficient, and to understand why it's fast and efficient, so that someday, if you come across a situation where map does not apply, you will know why, and you'll be able to use something better.

Being up in the clouds all the time is, to me, a pipe dream -- we must always be cognisant of the ground on which we built this tower of abstraction layers.

Prolog is declarative programming take to the maximum (excluding things like Answer Set Programming/clingo etc).

In Prolog you ask questions. For example: subset([1,2],[2]).

then it goes away and says "yes". Or you want to know if any subsets exist: subset([1,2],B).

B = [] B = [1] B = [2]

This makes it really really nice for some surprising tasks (Windows NT used to ship with a prolog interpreter for setting up the network)

I'm not sure I agree with some of the examples in the article. The examples used paint declarative programming as basically abstractions over details. The problem is that there is no line where an abstraction crosses the boundary into declarative programming. It's not really about abstractions but about control flow. If your code has a specific order it has to run in, then its imperative as you're still describing the steps needed to perform the action. SQL is declarative because you're describing the output set rather than the steps to generate it. Functional languages are considered declarative because of the fact that pure functions can be rewritten, optimized, lazy evaluated, etc by the runtime. I have a hard time considering map/reduce/etc in isolation as examples of declarative programming, as they're usually used in conjuction with an algorithm that most definitely has a defined execution order.

Map and other functional constructs may be declarative, but I only "feel" like I'm programming declaratively when I'm coding in a language like Prolog.

The fact that, with unification and backtracking, you can not only get a result for a query, but also "pass a variable" as an argument and get a possible value makes it seem much more like a mathematical expression and less like a computation.

For example, I can define some relations:

  parent_of(john, mary).
  parent_of(mary, eve).

  grandparent_of(X, Y) :- parent_child(X, Z), parent_child(Z, Y).

And then I can simply run a query:

  ?- grandparent_of(john, eve).
  Yes

But I can also make it fill in the value for me:

  ?- grandparent_of(john, X).
  X = eve

'grandparent_of' is not some piece of code, it's an actual declaration of a relation between the terms.

Of course, you can do unification and backtracking in other languages, but Prolog is designed for it.