enfp是什么意思网络用语(infp是什么意思网络用语)

魁首哥

作者

近年来，函数式编程发展突飞猛进。探讨该主题的书籍和会议数量激增、Scala 和 Clojure 等语言在快速普及，还有 John Carmack、Bob Martin 等名人的支持，都说明了这一事实。

如今，没有哪种新发布的编程语言不支持“函数式编程”，甚至保守温和、经过企业认证的 Java 也开始有了lambdas甚至monads。

是的，这是一个全新的世界。

为什么转向函数式编程？

我成为一名函数式编程软件工程师已经有四年多了。我喜欢 FP，每天都能学到更多东西。

最近我接受了一份短期合同，参与一个现有 Java 应用程序的开发工作。在开发这个应用程序（在我看来它基本可以算作是“企业级 Java“）时，我重新审视了自己喜欢上函数式编程的基本原因（时间一长，你会认为它们是理所当然的）。这些原因包括：

高阶函数（让你把函数传递给函数，或从函数中返回函数）帮助你在程序中剔除很多重复内容。我重构了现有的 Java 应用，改为使用高阶函数，并在此过程中发现和修复了几个错误（都与复制和粘贴的错误有关）。
不可变的数据结构在 FP 中经常使用，让你不必时刻担心代码会对传递的数据做什么奇怪的事情。在这个 Java 应用中，我发现了大量“防御性复制代码”。在我把许多核心数据结构从可变改为不可变后，轻松地删掉了这些复制代码。
强类型出现在许多函数式编程语言中（但不是全部），它告诉我们更多关于代码的静态验证属性的信息。在这个 Java 应用程序中，我把很多代码从使用 null 改为使用一个通用的可选数据结构，这样可以更清楚地传达值可能不存在的情况。于是，我也就能删除很多防御性的 null 检查，同时修复一些不常见代码路径中的 NPE。
纯函数，即没有副作用的函数（即它们的输出是其输入的确定性函数），更容易理解和测试，因为你不必怀疑函数的行为是否会根据隐藏状态而改变。在这个 Java 应用程序中，我将很多有状态的函数转换为无状态的函数，让代码更加简洁，并修复了一些错误。此外还有其他的一些好处（当然也有缺点），但总的来说，在这个 Java 应用程序中，我能够用较少的代码行修复错误并实现大量的新功能。

在我的经验中，这是很常见的收益。

这些好处是众所周知的。与 5 年前相比，今天的大多数程序员都听说过函数式编程，许多人都在使用 FP 中的一些技术（至少是高阶函数），而且越来越多的人加入进来，成为了 FP 的传教士。

FP 的“宗教信仰”

在函数式编程（FP）的光谱上，人们都落在了两个极端上。在一个极端，FP 是一种能够丰富指令式编程的方式（例如，将一个轻量级的回调传递给一个函数，或将一个块传递给一个循环）。而在另一个极端，FP 是一种编写所谓“纯”代码的方式——也就是没有副作用的代码，是纯粹的、参考透明的函数。

有些人已经深深地爱上了 FP（非常可以理解！），他们简直将 FP 当作了一种信仰。因此，我把它称为 FP 的“宗教信仰”。

但只要是“宗教”就会有一个问题，那就是可能存在盲目的教条主义。

对于 FP 来说，我认为它蒙蔽了许多人的眼睛，让他们看不清一些本该显而易见的东西。

函数式编程（不管其定义如何）并不是软件工程的目标。相反，它是达到目的的一种手段，就像软件工程师口袋里的其他工具一样。我知道这是异端邪说，所以让我来澄清一下。

软件工程的目标

作为一名软件工程师，我的工作一般来说是生产可运行、可理解，及可维护的软件。向我付费的人们大都希望开发结果包括以下几个方面：

代码能够可靠地工作，即使是应用程序中不经常使用的部分也是如此。
代码能被其他人轻易理解。我不会永远陪在他们身边解释代码。
编写代码时，尽量使未来的更改成本最小化。有一件事是不变的，那就是需求永远不会停止变化。当然，他们通常也希望代码既快又便宜，但这就是另一个主题了。

其实，他们的希望也是我所希望的。我喜欢没有 bug 的代码，这让我对自己的工作有一种自豪感，而且我讨厌调试。我希望我写的所有代码都容易理解，因为我可能需要在几个月或几年后再回来看这些代码（另外它有助于减少错误）。而且我非常喜欢那些组织得很好的代码，我可以很容易和安全地改变它以适应新的需求。

因此，如果软件工程的目标是正常运作的、可理解及可维护的软件，那么顺着这个逻辑提出的问题是：函数式编程能帮助我们实现它吗？

我的答案是：不一定。

流氓 FP

为了说明我的观点，我决定在函数式编程语言 Haskell 中实现快速排序。按照其主页上的描述，Haskell 是一种高级的、纯粹的函数式编程语言，目前也是我最喜欢的编程语言之一。

你几乎不可能在其他语言中得到比 Haskell 更多的“FP”基因了。所有用 Haskell 编写的程序都是纯函数式的（虽然有一些方法可以作弊，但我们在这里可以忽略不计）。

说到这里，请打起精神，看看我对快排的实现。

module Main (main) where import Control.Applicative import Data.Array.MArray import Data.Array.IO import Data.IORef type Array a = IOArray Int a whileM :: IO Bool -> IO () -> IO () whileM pred effect = do rez <- pred if rez then do effect whileM pred effect else return () quick_sort :: Ord a => Array a -> IO (Array a) quick_sort a = do (m, n) <- getBounds a let loop' = loop loop' a m (n + 1) where loop ary m n = if (n < 2) then return ary else do let readVal idx = readArray ary (idx + m) let writeVal idx = writeArray ary (idx + m) let readValRef ref = readIORef ref >>= readVal let writeValRef ref v = readIORef ref >>= writeVal <*> pure v pivotVal <- readVal $ n `div` 2 leftIdxRef <- newIORef 0 rightIdxRef <- newIORef $ n - 1 let incLeft = modifyIORef leftIdxRef (+1) let decRight = modifyIORef rightIdxRef (subtract 1) let readleftIdx = readIORef leftIdxRef let readRightIdx = readIORef rightIdxRef whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do leftVal <- readValRef leftIdxRef rightVal <- readValRef rightIdxRef if (leftVal < pivotVal) then incLeft else if (rightVal > pivotVal) then decRight else do writeValRef leftIdxRef rightVal writeValRef rightIdxRef leftVal incLeft decRight leftIdx <- readLeftIdx rightIdx <- readRightIdx loop a m (rightIdx + 1) loop a leftIdx (n - leftIdx) main = newListArray (0, 7) [9, 2, 3, 45, 2, 9, 2, 1] >>= quick_sort >>= getElems >>= putStrLn.show

尽管这个程序是“纯函数式的“，但它的代码是完全、彻底的垃圾：

当我第一次写好它后，它出现了几个 bug，我花了很多时间来追踪它们。
它很难理解。事实上，C 语言的实现可能会更容易理解。
对于这样一个小函数来说，它非常难以维护。安全地修改代码需要大量的思考和测试，而且你可能无法重用很多代码。注意，我用的词是“垃圾”。但我很清楚，有时不得不为编写系统级、性能优先的代码而付出代价。然而，对于大多数现代软件工程来说，情况并非如此。

上述就是一个纯粹的函数式程序，它与软件工程的目标完全无关。这是一个不那么典型的示范，但还有许多更能说明问题的现实范例，函数式程序员会很认同它们的。

这是 FP 的流氓行为，也证明了代码是“纯函数式“并不意味着就一定有什么价值。

可爱的 FP

现在我想给大家看一下 Haskell 中比较有名的快排例子。这并不完全是经典的快速排序，因为它并不是原地排序，但也足够接近了。

quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs

这才是优雅的实现！这也是为什么人们会这么喜欢 FP 的原因。

从定义上来说，这段代码的确是正确的。如果你了解 Haskell 的语法，它就很容易理解，而且没有什么排序代码比它更容易维护的了（好吧，filter 确实应该被 partition 取代，因为 filter 会破坏信息；使用 filter 需要手动否定布尔谓词< p，这代表了重复的信息内容）。

我们现在有两个纯粹的函数式程序，都是用同样的语言编写的，但两者之间却有天壤之别。

这是什么原因呢？