为什么命令式编程比函数式编程更受青睐?[关闭]


13

背景:我是函数式编程的支持者,他在VB.NET商店工作,那里的主流思维模型是命令式编程。作为我们系统的基础是WinForms,我可以理解我们不会完全摆脱命令式编程,但是我仍然尽可能尝试使用FP(主要是通过Linq),因为我相信它的优点。

针对FP的争论和反议

  1. 可能会注意到,流利的Linq效率不如命令式效率高,因为这种样式将一个序列处理为另一个序列并重复该序列。通常,与命令式方法相比,它需要花费更多的遍数,而命令式方法可以更好地进行优化以避免序列中的重复遍历。因此,主管无法理解为什么我会选择一种明显“效率较低”的功能方法。

    • 反对意见:我认为尽管有时它在CPU周期方面效率较低,但我认为它更人性化且易于理解,因为每一行在序列中仅做一件事。在我看来,这就像一条装配线,每个人在他的工作岗位上只能做一份工作。我觉得效率的微不足道的折衷通过代码的关注点得到了很好的补偿。
  2. 我在商店里听到的另一个反对FP的论点是,调试起来更困难-是的。跳过Linq代码并不容易。而且我有时确实必须解开方法链,以便更好地关注和剖析我无法立即发现的问题。

    • _Counter-argument:尽管在大多数情况下我对此没有疑问,因为我认为函数样式在其读取方式以及函数链中引发错误时更具声明性,我通常可以立即发现问题。

我的问题

我一直在尝试在我们的商店中推广实用风格,但我觉得自己没有取得进展。我已经完成了两种编程风格,直到最近才涉足Haskell。尽管有多年的命令性经验,但是现在我在JavaScript中常规使用FP,但在我看来,它已经发展起来。当我将它与如果我坚持命令式风格时可能会做的事情进行比较时,它在我的核心中留下了正确的音符。我已经对功能思维,功能组成进行了重新训练。

我无法理解的是,要说服其他人相信FP的优点是多么困难。

例如,我店里的开发人员确实使用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

我喜欢函数式编程,但是从快速查看代码的角度来看,我更喜欢“命令式”(我称为声明式)方法。对我来说,阅读起来要容易得多,因为这可能是我的经验,也是我所处环境的产物。就是说,在短短的5秒钟内,我可以看到准备步骤和返回的内容。我可以看到有一个循环,并且知道对数据的调整很可能会在其中进行。我不必追踪功能定义;它在那里,很简单。但是FP更干净,一旦超过了学习曲线,编写代码的速度可能会一样快。
vol7ron

问题在于学习曲线,特别是在与只懂多种语言的人一起工作时。如果专精于任何特定语言,我相信FP将是更好的首次尝试。然后,如果存在效率低下(单元测试性能)的情况,则在其实现中可能会更明确。
vol7ron

Answers:


11

对于没有经验的程序员来说,函数式编程太复杂了。其中的插图是这一个,这里的学生宣称,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之类的语言进行编程的原因。


8
我在一所大学使用相反的经验,该大学将Scheme用于入门课程。当学生不得不学习Java或C#时,大多数人抱怨Scheme更具可读性
Daniel Gratzer 2013年

2
这证明了我的意思。多年学习命令式编程和OOP的学生会发现它更具可读性。与命令式编程相比,使用FP入门的人会发现它更具可读性。知道对FP和非FP范例同样了解的学生会发生什么会很有趣。
阿森尼·穆尔琴科

1
主要的问题是功能语言要抽象得多。当Haskeller告诉您由于积累了未评估的重击而使内存用尽时,肯定存在问题。以功能样式编写的许多算法效率不高。您无法实现快速的Quicksort展示。在惯用的Haskell中。为了获得良好的性能,每种就地算法最终都会做IO阵列。功能语言是为语言纯粹主义者提供的,命令性语言是为希望及时完成思考的人们提供的。
Kr0e 2014年

3
@ Kr0e:对某种语言或范例的“抽象太多”的论点在我看来总是很奇怪。对所有(或大多数)语言使用了相同的论点。希望大多数软件不是今天用汇编语言编写的。
Arseni Mourzenko 2014年

6
“功能性语言是针对语言纯粹主义者的,命令性语言是针对希望及时完成思考的人们的。”:根据我的经验,这是不正确的。使用函数式语言,我可以更快地完成工作。命令式的样式更加冗长,声明式的较少,当我不得不使用命令式语言时,我肯定需要做更多的迭代才能使事情变得正确。
Giorgio 2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.