Functional vs. imperative

[jsmith]

There have been recent posts in which small programs were written in
both an imperative language (such as C++) and a functional language
(such as Scala) and comparisons made. Often times the comparisons
were to the effect that the functional language implementation was
shorter than the imperative.

I myself am not against functional programming in any way; in fact,
I try to write my C++ code as close to functional as is reasonable,
mostly because functional implementations are easier to prove
correctness of than imperative and because fewer lines of code
means less opportunity for bugs.

While there are perhaps an equal number of functional languages
available as there are imperative, I would venture a guess that
the amount of code written in C and C++ is much larger than the
sum of the code written in all functional languages combined.

So why is that? Thoughts? Comments?

[PanGalactic]

I find imperative languages allow me to map complex interactions better than functional ones. I'm with you on writing in a functional style. But I do that at the lower level. I still need to model complex behaviors across multiple boundaries. I find that tying action and reaction together in a functional model is difficult. It could be that I just never learned how to do that properly.

In the end I suspect it is because it is easier to express complex interactions in an slightly inexact way (can't prove correctness) that makes it more manageable for the average human brain.

I would have a hard time using languages that do not have functional capabilities. I get most of what I need out of the STL and Boost though: generators (Boost generator iterator adapter), map (transform), reduce (accumulate), currying (boost::bind), lambdas (Boost, soon c++0x), etc.

[helios]

Because it's easier to find imperative programmers than functional programmers, because more programmers learn imperative languages, because there are more jobs that require imperative programming.
My opinion on the source of this cycle is that, while functional programming is no doubt a handy notation, a) computers (at least classical computers) are naturally huge state machines, and b) it's more natural to think about algorithms as a sequence of steps that change some state.
Other factors may include the fact that people don't like too much abstraction (e.g. NIH syndrome. I remember one particularly heinous case where a system's scope grew so much, it essentially reimplemented some or most of the OS's functions. I wish I had a link to the story).

[EzwRko23]

Functional is good, because of immutable, persistent data structures. You can safely pass a pointer/reference anywhere and you are guaranteed no one will corrupt it. Because the only way to operate on these structures is by making copies of them, making copies is an extremely well optimized operation.

It is also great how easy you can do an UNDO operation in the program (which is extremely difficult in imperative style - just get the recent OpenOffice version to see how undo can be broken) . Just put all the states on the stack. When using persistent data structures, it is suprisingly cheap (memory- and time-wise).