Why is imperative programming preferred over functional programming?

Question

Background: I am proponent of functional programming who works at a VB.NET shop where the prevailing mental model is imperative programming. Being that foundation of our system is WinForms I can understand we're not going to get entirely away from imperative programming, but still I try to use FP (primarily via Linq) wherever possible because I believe in its merits.

Arguments & counter-arguments against FP

1. One might notice that fluent Linq is less efficient than its imperative counterpart in that this style processes a sequence down to another sequence and repeats that. Generally, its going to take a few more passes than the imperative approach which can be better optimized to avoid repeat passes over a sequence. For this reason, the lead couldn't understand why I would choose a functional approach that is clearly "less efficient."

   • Counter-argument: I argued that while it is sometimes less efficient in terms of CPU cycles, that I felt it is more humanly intelligible and easy to follow since each line does just one thing on its pass over the sequence. To me this feels like having an assembly line where each person at his station has just one job to do. I feel that the negligible trade off of efficiency is recompensed by code whose concerns are neatly separated.

2. The next argument against FP that I hear in my shop is that it's harder to debug -- which is true. It's not easy to step over Linq code. And I do sometimes have to unravel a method chain in order to better follow and dissect issues that I can't immediately spot.

   • _Counter-argument: For the most part though I don't have issue with this because I think the functional style is more declarative in how it reads and when an error is thrown within a functional chain, I can usually spot the issue immediately.

My Question

I've been trying to promote functional style in our shop and I don't feel like I'm making headway. I've done both styles of programming and have only recently dabbled in Haskell. Despite years of imperative experience, now that I'm making routine use of FP in JavaScript, it's grown on me. It rings a note of rightness in my core when I compare it to what I might have done if I stuck to an imperative style. I've retrained my brain toward functional thinking, toward functional composition.

What I can't understand is how hard its been to convince others of FP's merits.

For example, the developers in my shop do use Linq, but I think they generally use it in the context of dealing with domain data. I use it in a more general sense and prefer it anytime I'm dealing with sequences/lists or persistent data structures. I haven't been able to convince my teammates to expand their use of Linq.

What I'm trying to understand is what causes a developer to not like FP.

I would like to see an answer from someone who has a good deal of experience with FP but decided in favor of the imperative style. What drove the decision to stay with imperative instead of using functional?

---

Here's an additional example highlighting the differences between imperative & functional programming.

I wrote the SelectedRows method of our grid in Linq as such:

Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows
    Get
        Return Me.ugrBase.Selected.Rows.
            OfType(Of Infragistics.Win.UltraWinGrid.UltraGridRow)().
            Select(Function(ugr) ugr.ListObject).
            OfType(Of DataRowView)().
            Select(Function(drv) drv.Row).
            ToArray
    End Get

However, this style of code makes some of our developers uncomfortable and so our lead rewrote it to the more familiar:

Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows
    Get
        Dim plstRows As New List(Of DataRow)
        For Each bugrLoop As Infragistics.Win.UltraWinGrid.UltraGridRow In Me.ugrBase.Selected.Rows
            If bugrLoop.ListObject IsNot Nothing Then
                plstRows.Add(CType(bugrLoop.ListObject, DataRowView).Row)
            End If
        Next
        Return plstRows.ToArray()
    End Get

Answer 1

Functional programming is just too complicated for inexperienced programmers. One of the illustrations is this one, where students declared that 30-LOC mess was easier and more intuitive to understand compared to the four lines FP analog.

(This is the original version of the FP example, as the answer in the link has been more recently edited to make it slightly easier to read.)

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

Functional programming requires a different way of thinking about the way we code and the way this code is executed. This is rarely the way the students are told in college, and once bad habits taken, it's difficult to change them.

Functional programming has also its own specific features which may appear risky in hands of beginners. Lazy evaluation is one of them, and it may take months before one starts to understand why lazy evaluation is an excellent feature, and not an annoyance.

That's also why so many beginners start programming with languages such as PHP and not languages like Haskell.