Return to Answer

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:

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

The next higher level of abstraction is functional programming, where you pass a function ( in this case a C# lambda expression ) to a library function to operate on the collection. The library function hides the iteration aspects.

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

Here, we're calling a function which says "Step through the collection, building a collection of the items which are odd." We don't have to manage the result collection ourselves, and the result collection itself might not be evaluated until something iterates over it.

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 = from num in collection where num % 2 != 0 select num; 

Here, we're saying "Give us everything where it's odd". If the compiler knew that collection was an Sql object, then instead of generating the functional code as it would for an in-memory collection, it would generate the appropriate SQL calls.

In the imperative version, you decided how and when to iterate over the collection.

In the functional version, the library decided how and when to iterate over the collection.

In the declarative version, the compiler for the declarative sub-language decided whether iterating over the collection was even necessary, or whether to pass it to the SQL back end.

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

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:

1. Create a result collection
2. Step through each number in the collection
3. 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.

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:

1. Create a result collection
2. Step through each number in the collection
3. 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.

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:

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

The next higher level of abstraction is functional programming, where you pass a function ( in this case a C# lambda expression ) to a library function to operate on the collection. The library function hides the iteration aspects.

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

Here, we're calling a function which says "Step through the collection, building a collection of the items which are odd." We don't have to manage the result collection ourselves, and the result collection itself might not be evaluated until something iterates over it.

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 = from num in collection where num % 2 != 0 select num; 

Here, we're saying "Give us everything where it's odd". If the compiler knew that collection was an Sql object, then instead of generating the functional code as it would for an in-memory collection, it would generate the appropriate SQL calls.

In the imperative version, you decided how and when to iterate over the collection.

In the functional version, the library decided how and when to iterate over the collection.

In the declarative version, the compiler for the declarative sub-language decided whether iterating over the collection was even necessary, or whether to pass it to the SQL back end.

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

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 == 1) results.Add(num); } 

Here, we're saying:

1. Create a result collection
2. Step through each number in the collection
3. 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 == 1 ); 

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.

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:

1. Create a result collection
2. Step through each number in the collection
3. 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.