Почему императивное программирование предпочтительнее функционального программирования? [закрыто]

Фон: я сторонник функционального программирования, который работает в магазине VB.NET, где преобладающей ментальной моделью является императивное программирование. Поскольку основой нашей системы является WinForms, я могу понять, что мы не собираемся полностью уходить от императивного программирования, но все же я стараюсь использовать FP (главным образом через Linq) везде, где это возможно, потому что верю в его достоинства.

Аргументы и контраргументы против FP

1. Можно заметить, что беглый Linq менее эффективен, чем его императивный аналог, поскольку этот стиль обрабатывает последовательность до другой последовательности и повторяет ее. Как правило, это займет несколько больше проходов, чем императивный подход, который можно лучше оптимизировать, чтобы избежать повторных проходов по последовательности. По этой причине руководитель не мог понять, почему я выбрал бы функциональный подход, который явно «менее эффективен».

   • Контр-аргумент : я утверждал, что, хотя иногда он менее эффективен с точки зрения циклов ЦП, я чувствовал, что он более понятен человеку и его легко понять, поскольку каждая строка выполняет только одну вещь при прохождении последовательности. Для меня это похоже на сборочную линию, где у каждого человека на его станции есть только одна работа. Я чувствую, что незначительный компромисс эффективности компенсируется кодом, чьи проблемы четко разделены.

2. Следующий аргумент против FP, который я слышу в своем магазине, заключается в том, что его сложнее отлаживать - и это правда. Нелегко перешагнуть через код Linq. И мне иногда приходится распутывать цепочку методов, чтобы лучше отслеживать и анализировать проблемы, которые я не могу сразу заметить.

   • _Counter-аргумент: по большей части, хотя у меня нет проблем с этим, потому что я думаю, что функциональный стиль более декларативен в том, как он читает, и когда выдается ошибка в функциональной цепочке, я обычно могу сразу определить проблему.

Мой вопрос

Я пытался продвигать функциональный стиль в нашем магазине, и я не чувствую, что продвигаюсь вперед. Я занимался обоими стилями программирования и только недавно баловался с Haskell. Несмотря на многолетний опыт, теперь, когда я регулярно использую FP в JavaScript, он вырос на мне. Когда я сравниваю это с тем, что я мог бы сделать, если бы придерживался императивного стиля, это звучит как примечание правильности в моей сути. Я переучил свой мозг на функциональное мышление, на функциональную композицию.

Я не могу понять, как трудно убедить других в достоинствах ФП.

Например, разработчики в моем магазине используют Linq, но я думаю, что они обычно используют его в контексте работы с данными домена. Я использую это в более общем смысле и предпочитаю это всякий раз, когда имею дело с последовательностями / списками или постоянными структурами данных. Я не смог убедить своих товарищей по команде расширить использование Linq.

Я пытаюсь понять, что заставляет разработчика не любить FP.

Я хотел бы получить ответ от кого-то, кто имеет большой опыт работы с FP, но решил в пользу императивного стиля. Что привело к решению остаться с императивом вместо использования функционала?

Вот дополнительный пример, подчеркивающий различия между императивным и функциональным программированием.

Я написал SelectedRowsметод нашей сетки в Linq как таковой:

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

Однако этот стиль кода делает некоторых наших разработчиков неудобными, и поэтому наше руководство переписало его на более привычное:

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

Функциональное программирование слишком сложно для неопытных программистов . Одна из иллюстраций - это тот , где студенты заявили, что беспорядок 30-LOC был легче и более интуитивно понятен по сравнению с четырехстрочным аналогом FP.

(Это оригинальная версия примера FP, поскольку ответ в ссылке был недавно отредактирован, чтобы его было немного легче читать.)

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)));

Функциональное программирование требует другого подхода к тому, как мы кодируем и как этот код выполняется. Это редко так, как учат студентов в колледже, и как только вредные привычки приняты, их трудно изменить.

Функциональное программирование также имеет свои особенности, которые могут оказаться рискованными в руках новичков . Ленивая оценка - одна из них, и могут пройти месяцы, прежде чем вы начнете понимать, почему ленивая оценка - отличная функция, а не раздражение.

Вот почему так много начинающих начинают программирование на таких языках, как PHP, а не на таких языках, как Haskell.