Differencebetween Declarative and Imperative Paradigm in Programming

What is the difference between declarative and imperative paradigm in programming?

A great C# example of declarative vs. imperative programming is LINQ.

With imperative programming, you tell the compiler what you want to happen, step by step.

For example, let's start with this collection, and choose the odd numbers:

List<int> collection = new List<int> { 1, 2, 3, 4, 5 };

With imperative programming, we'd step through this, and decide what we want:

List<int> results = new List<int>();
foreach(var num in collection)
{
    if (num % 2 != 0)
          results.Add(num);
}

Here, we're saying:

Create a result collection
Step through each number in the collection
Check the number, if it's odd, add it to the results

With declarative programming, on the other hand, you write code that describes what you want, but not necessarily how to get it (declare your desired results, but not the step-by-step):

var results = collection.Where( num => num % 2 != 0);

Here, we're saying "Give us everything where it's odd", not "Step through the collection. Check this item, if it's odd, add it to a result collection."

In many cases, code will be a mixture of both designs, too, so it's not always black-and-white.

Difference between declarative and imperative in React.js?

A declarative style, like what react has, allows you to control flow and state in your application by saying "It should look like this". An imperative style turns that around and allows you to control your application by saying "This is what you should do".

The benefit of declarative is that you don't get bogged down in the implementation details of representing the state. You're delegating the organizational component of keeping your application views consistent so you just have to worry about state.

Imagine you have a butler, who is kind of a metaphor for a framework. And you would like to make dinner. In an imperative world, you would tell them step by step how to make dinner. You have to provide these instructions:

Go to the kitchen
Open fridge
Remove chicken from fridge
...
Bring food to the table

In a declarative world, you would simply describe what you want

I want dinner with chicken.

If your butler doesn't know how to make chicken, then you cannot operate in a declarative style. Just like if Backbone doesn't know how to mutate itself to do a certain task, you can't just tell it to do that task. React is able to be declarative because it "knows how to make chicken", for example. Compared to Backbone, which only knows how to interface with the kitchen.

Being able to describe the state reduces the surface area for bugs dramatically, which is a benefit. On the other hand, you might have less flexibility in how things occur because you're delegating or abstracting away how you implement the state.

What is the difference between declarative and procedural programming paradigms?

Imperative

There are several sub-paradigms of the imperative programming paradigm, such as the procedural or the object-oriented programming paradigms.

In the imperative programming paradigm, you describe the algorithm step-by-step, at various degrees of abstraction.

Examples of programming languages which support the procedural paradigm:

C (and most other legacy languages)
PHP, mostly
In some sense, all major languages

Object-Oriented

It typically refers to languages that exhibit a hierarchy of types that inherit both methods and state from base types to derived types, but also includes the unusual prototype-based JavaScript.

Examples of programming languages which support the OO paradigm:

Java

Declarative

There are several sub-paradigms of the declarative programming paradigm, such as the functional or the logic programming paradigms.

In the declarative programming paradigm, you describe a result or a goal, and you get it via a "black box". The opposite of imperative.

Examples of programming languages which support the declarative programming paradigm:

yacc
Treetop
SQL
Regular Expressions
lex
XSLT
markup, troff, CSS, VHDL

Functional

Functional programming emphasizes the application of functions without side effects and without mutable state. The declarative systems above exhibit certain aspects of functional programming.

Examples of programming languages which support the declarative functional paradigm:

Haskell
OCaml
Scheme
Erlang
F#
Scala

Functional programming: Declarative vs imperative

So first of all, functional programming and imperative programming are
equivalent when it comes down to brass tacks, as shown by the Church-Turing
theorem. Anything that can be done by one can be done by the other. So while I
really prefer functional languages, I can't make a computer do anything that
can't be done in an imperative language.

You'll be able to find all kinds of formal theories about the distinction
with a quick google search so I'll skip that and try to illustrate what I like
using some pseudocode.

So for example, let's say I have an array of integers:

var arrayOfInts = [1, 2, 3, 4, 5, 6]

And I want to turn them into strings:

function turnsArrayOfNumbersIntoStrings(array) {
  var arrayOfStrings = []
    for (var i = 0; i < arrayOfInts; i++) {
      arrayOfStrings[i] = toString(arrayOfInts[i])
    }
  return arrayOfStrings
}

Later, I'm making a network request:

var result = getRequest("http://some.api")

That gives me a number, and I also want that to be a string:

function getDataFromResultAsString(result) {
  var returnValue = {success:, data:}
  if (result.success) {
    returnValue.success = true
    returnValue.data = toString(data)
  }
  return returnValue
}

In imperative programming, I have to describe how to do what I want.
Those functions are not interchangeable because going through an
array is obviously not the same as doing an if statement. So turning their
values to strings is totally different, even if they both call the same toString
function.

But the shape of those two steps is exactly the same. I mean if you squint a
a little bit, they are the same function.

How they do it has to do with a loop or if statement, but what they do is take
a thing that has stuff in it (either array with ints or request with data) and
turn that stuff into a string, and return.

So maybe we give the things a more descriptive name, that applies to both. They
are both a ThingWithStuff. That is, an array is a ThingWithStuff, and a request
result is a ThingWithStuff. There is a function for each of them, generically
called stuffToString, that can change the stuff inside.

One of the things functional programming has is first order functions: functions
can take functions as arguments. So I could make it more general with something
like this:

function requestStuffTo(modifier, result) {
  var returnValue = {success:, data:}
  if (result.success) {
    returnValue.success = true
    returnValue.data = modifier(data)
  }
  return returnValue
}

function arrayStuffTo(modifier, array) {
  var arrayOfStrings = []
    for (var i = 0; i < arrayOfInts; i++) {
      arrayOfStrings[i] = modifier(arrayOfInts[i])
    }
  return arrayOfStrings
}

Now the functions for each type keep track of how to
change their internals, but not what. If I want a function that turns an array
or request of ints to strings, I can say what I want:

arrayStuffTo(toString, array)
requestStuffTo(toString, request)

But I don't have to say how I want it, because that was done in the earlier
functions. Later, when I want array and request of say, booleans:

arrayStuffTo(toBoolean, array)
requestStuffTo(toBoolean, request)

Lots of functional languages can tell which version of a function to call by the
type and you can have multiple definitions of the function, one for each type.
So that can be even shorter:

var newArray = stuffTo(toBoolean, array)
var newRequest = stuffTo(toBoolean, request)

I can curry the arguments, then partially apply the function:

function stuffToBoolean = stuffTo(toBoolean)

var newArray = stuffToBoolean(array)
var newRequst = stuffToBoolean(request)

Now they are the same!

Now, when I want to add a new ThingWithStuff type, all I have
to do is implement stuffTo for that thing.

function stuffTo(modifier, maybe) {
  if (let Just thing = maybe) {
    return Just(modifier(thing))
  } else {
    return Nothing
  }
}

Now I can use the functions I already have with the new thing, for free!

var newMaybe = stuffToBoolean(maybe)
var newMaybe2 = stuffToString(maybe)

Or, I can add a new function:

function stuffTimesTwo(thing) {
  return stuffTo((*)2), thing)
}

And I can already use it with any of the things!

var newArray = stuffTimesTwo(array)
var newResult = stuffTimesTwo(result)
var newMaybe = stuffTimesTwo(newMaybe)

I can even take an old function and easily turn it into
one that works on any ThingWithStuff:

function liftToThing(oldFunction, thing) {
  return stuffTo(oldFunction, thing)
}

function printThingContents = liftToThing(print)

(ThingWithStuff is usually called Functor, and stuffTo is generally called map)

You can do all the same things in an imperative language, but for example
Haskell already has hundreds of different shape things and thousands of
functions that work on those things. So if I add a new thing, all I have to do
is tell Haskell what shapes it is and I can use those thousands of functions
that already exist. Maybe I want to implement a new kind of Tree, I just say
Tree is a Functor and I can use map to alter its contents. I just say it's an
Applicative and with no more work I can put functions inside it and call it like
a function. I say it's a Semiring and boom, I can add trees together. And all
the other stuff out there that already works for Semirings just works on my
Tree.

What's the difference between declarative and imperative programming?

Declarative programming - What should be done

Imperative programming - How what you want should be done.

Declarative programming requires developers to say what is to be done. Imperative programming requires developers to define step by step how code should be executed.

Example: LINQ in C# is declarative.

Read here for more: http://www.informit.com/articles/article.aspx?p=1330154&seqNum=4