背景:我是函数式编程的支持者,他在VB.NET商店工作,那里的主流思维模型是命令式编程。作为我们系统的基础是WinForms,我可以理解我们不会完全摆脱命令式编程,但是我仍然尽可能尝试使用FP(主要是通过Linq),因为我相信它的优点。
针对FP的争论和反议
可能会注意到,流利的Linq效率不如命令式效率高,因为这种样式将一个序列处理为另一个序列并重复该序列。通常,与命令式方法相比,它需要花费更多的遍数,而命令式方法可以更好地进行优化以避免序列中的重复遍历。因此,主管无法理解为什么我会选择一种明显“效率较低”的功能方法。
- 反对意见:我认为尽管有时它在CPU周期方面效率较低,但我认为它更人性化且易于理解,因为每一行在序列中仅做一件事。在我看来,这就像一条装配线,每个人在他的工作岗位上只能做一份工作。我觉得效率的微不足道的折衷通过代码的关注点得到了很好的补偿。
我在商店里听到的另一个反对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