请教关于函数式编程的优势

资深函数式码农（自封）来扯两句:
于我而言函数式最大的优势在于，容易写对，且容易分析，容易理解。同时附带了容易并行的优势
而执行速度，函数式写法确实慢于专家优化过的指令式，但比普通 CRUD 农写的指令式代码更快是基本操作了。

说句不好听的，见过大量在复杂业务逻辑盲目使用方式二导致的性能和阅读困难

对我而言就两点好处：
1. 提供操作符减少了部分操作代码编写
2. 整个代码结构从上到下就是对应逻辑链条，熟悉操作符很快就能看懂逻辑了
支撑使用的原因就是第二条了

因为 Java 的函数式本来就是残废的。

像 Haskell 这类正统的函数式语言，默认珂里化，甚至参数都不用写全。灵活又高效。

另外函数式编程最大的爽点是无副作用所带来的心智负担的降低；以及超高的鲁棒性。在这两点好处面前，性能的些微下降不值一提。

第一种我必须人脑运行一次才能理解发生了什么；第二种虽然能一眼看明白在干啥，但是写的有点恶心，但我认为这是 Java 的问题，用 Kotlin 就好了

函数式写法很大程度上是为了增加可读性，但 op 你发的这个写法 2 个人认为挺拉的。
可读性没降低多少，时间复杂度从 n 升级到 n * log n 。

写法 2 性能差不是 fp 的原因，而是楼主没能等价改写。
实际上这里应该用 foldLeft 而不是 sorted/findFirst
在 java stream api 中应该 reduce 是可以用的
这样两段代码复杂度就一样了

如果是我的话可能会这样写：

https://imgur.com/YBBKeIT

来个 kotlin 版本，比 java stream 舒服很多。（吹爆 kotlin

```kotlin
data class Book(val category: String, val price: Double)

fun mostExpensiveByCategory(books: List<Book>): Map<String, Book> {
return books.groupBy { it.category }
.mapValues { (_, books) -> books.maxBy { it.price } }
}
```

函数式一般可以把算法轻松地拆分成多个步骤。
第一种写法的坏处就是在任何一个时间点的数据都缺乏一致性，即一半数据处理了，一半数据没处理。
如果数据出错，你打断点拿到的也是这样一半一半的数据。
函数式这样每次跑一步出来都是完整的数据集，一眼就能找到问题点。

一次遍历就可以了，感觉楼上代码都被楼主带偏
每个 key 对应单值而不是集合的优先考虑 Collectors.toMap()

dataSource.stream().collect(Collectors.toMap(Book::getCategory, Function.identity(),
(o1, o2) -> o1.getPrice().compareTo(o2.getPrice()) > 0 ? o1 : o2)).values();

理论上总能用 lambda 写出一样的复杂度，只是可能有 API 的限制

这点数据 循环一次和循环几次没啥差别, 我的原则是能一行代码解决的 不写七八行.

链式调用并不是函数式编程的专利，函数式编程的核心特征是不对变量进行重复赋值

函数式编程很多时候都会牺牲一定的性能，但是获得了可读性上的增强。
我个人很喜欢在 Javascript 里面使用函数式，比如说组合函数，纯函数，hof 等等，但是同事都不是很认可，后来放弃了。只在自己的项目里面用。

Java 可真残废 (doge )

可读性强，可测试性高，可并行化改造，可以从组合的维度思考问题。同时流程清晰，可以很方便的进行优化，包括语法编译层面的优化。

@lerefe @july1995 不好意思，看错了 :->

简单场景下，虽然第二种方式可读性更高一些。
但是因为是简单场景，完全可以给这个方法加一行注释 “按照 xxx 分组，获取每个分组内 xxx 最小的元素”
来解决可读性差的问题。

但是第二种写法的扩展性就不如第一种了，如取分组内最小的和第二小的，改起来逻辑就没这么顺了。

@lmshl zio 好用吗？

楼主在看哪本书啊？ 可以推荐一下学习资料吗？

@WispZhan
akka-stream 、zstream 、fs2 都有上生产环境，目前用下来总体感觉 zio 的模型是上手最快，最容易写的。

akka-stream 的错误处理建模会很恶心，fs2 和 zstream 差不多但是 zstream 的类型没有 fs2 那么高理解成本。

@yayiji 请问这个原文哪里有？

@Mistwave
来自 架构整洁之道

「如你所见，我在介绍三个编程范式的时候，有意采用了上面这种格式，目的是凸显每个编程范式的实际含义它们都从某一方面限制和规范了程序员的能力。没有一个范式是增加新能力的。也就是说，每个编程范式的目的都是设置限制。这些范式主要是为了告诉我们不能做什么，而不是可以做什么。

另外，我们应该认识到，这三个编程范式分别限制了 goto 语句、函数指针和赋值语句的使用。那么除此之外，还有什么可以去除的吗？

没有了。因此这三个编程范式可能是仅有的三个了如果单论去除能力的编程范式的话。支撑这一结论的另外一个证据是，三个编程范式都是在 1958 年到 1968 年这 10 年间被提出来的，后续再也没有新的编程范式出现过。」

仅从题主的例子来说，
第 1 点不同是可读性，imperative VS declarative ，
第 2 点关于复杂度的担忧（循环），同样是函数式的写法可以用 fold / reduce, 另外尽量用 transducer ，看上去很多的 transformer 实际上也只是循环一次。(不清楚 java 是否有类似的东西，https://clojure.org/reference/transducers 是 clojure 在性能方面的考量和努力）

@TWorldIsNButThis 换一种说法，好像就是把代码从命令式变成声明式