Never knew it. Never will. 
why?
Imperative Programming languages aren't the best tool for everything. Most people just think they are.
Declarative Programming Languages have plenty of applications and there are plenty of situations where they are ideal. SQL, for example. The focus is not on
how the program does what it does, but more on what it does. This means that for the most part you are usually limited in some way as to what you can tell it to do. On the other hand, you can still get it to do just about anything. People have written SQL queries that generate ASCII mandelbrots, for example.
Functional Programming, like F#, Lisp, scheme, and if you want to, even segments of C# can be written in a "functional" way. For the most part, it's similar to Declarative programming- in fact, Functional Programming is in many ways a subset of Declarative programming, but with a focus on solving problems through recursion. The only way for somebody used to an imperative style to understand the Functional style is through contrast.
Say you have a list in C. And you want to pull out every Xth element. You'll have to point at the first element. set a counter to 0. Then, you add X to that counter until X is greater than the size of that list, and with every item, add it to a new list.
The equivalent in a functional language would be to write a function (surprised?) that recognizes when the size of a list is a multiple of X, and then
pass that function to the list, possibly with another snippet of code (a lambda, for example) to hand back the head of your list if your X-recognizer evaluates to true, and discard it if it evaluates to false. The two functions recurse through the list and finally hand back a list consisting of every Xth element.
For example, let's say you have a List<String> (List of Strings) in C#. Since C# supports both programming models, the contrast can be most apparent. the "Traditional" method might work like this:
public List<String> EveryX(List<String> OfList,int X)
{
List<String> returnlist = new List<String>();
int i=0;
for(i=0;i<OfList.Count();i+=X)
{
returnlist.Add(OfList[i]);
}
return returnlist;
}
(note, might not be 100% accurate, but the jist is about right). Now, compare that to the functional way to do the same thing:
List<String> everyN = list.Where((x, i) => i % (n-1) == 0);
The latter method is shorter, but might seem more confusing. And in a way, it is. Functional Programming can be a mind bender, which is one reason why Lisp, Scheme, Haskell, Prolog, and other declarative/functional languages have never really surpassed C, C++, Java, COBOL, or other imperative languages in commercial popularity. But there are benefits to the functional way of doing things. For one thing, if you can get the logic correct, functional programming requires orders of magnitude less code than the imperative approach. That means fewer points of failure, less code that needs tested, and in general a more productive (and happier) programming experience. As systems get bigger, this is starting to become more and more important.
The industry is young, and yet so many people seem to think that we're at the "mountaintop" when it comes to the tools we use and the hardware we use and so forth. C/C++, and other imperative languages are not the be-all end all of programming languages, and so-called programmers who discount other programming styles as "novel" simply because they do not understand their paradigms is possibly one of the things holding back Software development as an industry and keeping it in some weird Limbo between arcane wizardry, gambling, and art.
