下午好 最近，我经常听到PLO的日落即将到来。 今天，越来越多的人正在转向功能范式。 很快，用C ++ / C＃/ Java编写的人员将一无所获。 是这样吗 我不这么认为。 在我看来，不加思索地使用FP（函数式编程）会变得很耗时，而且更令人头疼，这与当前的设计决策完全不兼容。 让我们确保它！
我要注意：这与Java / Python中的lambda表达式无关，而与Haskell或Scala和cats / scalaz等更高级的FP有关。
因此，我确认：
- AF并非在任何地方都适用。
- 当与现成的解决方案集成时，这会令人头疼。
- 在自动对焦上花费时间并不总是明智的。
我们将更详细地分析这些问题并评估悲剧的规模。
1. AF远非在任何地方都适用
这似乎令人惊讶，但是并不是每个人都理解这一点。 而且，像C这样的语言距离日落还很遥远。 比Haskell或Scala更远。 看看任何游戏引擎。 很有可能以90％的概率用C编写代码。看看公寓中任何家用设备的固件。 很有可能这又是C！ 操作系统？ 当然是C。
为什么会这样呢？ 事实是以上所有这些都直接与铁一起使用。 铁不知道任何高阶函数。 Iron是一组寄存器（已经是可变状态），中断（同样会改变状态）和将零和一从一个单元传输到另一个单元的命令。
当然，您可以使用抽象，而忽略所有这些铁的东西。 但是首先，这并不总是合理的。 如果我们的程序很简单，那么没有必要关闭某些抽象层。 其次，通常在这样的程序中，工作速度被放在关键位置之一上。 因此，“解释” FP压盖的额外费用将完全破坏您的开发收益。 AF无法在此处显示。
2.与交钥匙解决方案集成时令人头疼
每种自重的编程语言都有大量现成的解决方案。 在C＃中，它是例如Entity Framework和.Net。 在Java中，它们是Hibernate和Spring。 几乎每个框架都旨在以我们通常的OOP风格工作。 这些解决方案几乎总是具有可变状态，并且完全不适合用于纯相变。
任何核心的函数式程序员都会说，您需要丢弃这些解决方案，并在没有它们的情况下进行工作。 好吧 让我们找出来，以供参考：
- 这样的决定几乎总是导致样板代码。
- 我们正在失去巨大的功能层。 当然，我们可以使用现成的库在功能范例中工作。 但是，几乎总是这样的解决方案不那么受欢迎，这意味着它不能提供流行解决方案的所有可能性的一半。
- 使用此解决方案的成品几乎需要完全重构。
- 我们正在失去经过充分测试和高度确定性的解决方案。 相反，我们正在走向未知。 流行的解决方案是否存在任何问题？ 当然可以！ 但是关于它们的规则，早已众所周知。 在我们的新方法中，这绝对不会发生。
实际上，该列表持续了很长时间。 在我看来，总的损失至少使AF无法在任何地方使用，也不总是适用。
3.在自动对焦上花费时间并不总是明智的令人惊讶的是，程序员常常看不到代码的背后是什么。 并非总是由编程语言和范例来决定产品的质量。 在背面，所有东西都放在容器化上。 您写的内容几乎并不重要：Python，Java，Scala。 这些语言中的任何一种的代码都可以包装在图像中并作为容器交付。
在这样的世界中，如果容器满足所有设定的要求，那么容器内部的内容就不那么重要了。 在这里，整个系统的组织方式更为重要。 问题就来了：您真的确定应该花时间来研究FP的范畴论吗？ 可能需要投资开发整个系统体系结构。 此外，查找不具备FP知识并准备为您提供此类容器的人员要容易得多。
想象一下这种情况。 您晚上坐下来研究整个理论。 您可以在YouTube上观看视频，看书，深入研究数学计算。 随着时间的流逝，您已经可以构建一个小型应用程序，但是并不是所有事情都是明确的。 您将开始进一步练习：学习更高级的书籍，参加会议，与同事进行有关高级的对话。 但是随后出现了一个真正的项目。 凭借您的知识，您将成为该项目的领导者。 生活是美好的！ 因此，您编写的只是完美的服务。 仅剩下一个问题。 接下来要做什么？ 如何配置自动化过程？ 如何设置智能平衡？ 如何找到您的其他服务？ 您可能根本无法回答这些问题！ 您是否仍然确定自动对焦对您如此必要？
结论
实际上，我对AF持非常积极的态度。 我想说的是一种远非总是无处不在的工具。 我认为，工程师不应在喜欢/不喜欢的类别中进行思考。 相反，应该有使用该解决方案的最客观的原因。
在学习/引入功能范例之前，应该至少问三个问题：在您的专业领域中应用的可能性，与现成的解决方案集成时会影响多少，以及是否可以节省时间和资源。 如果您没有因任何这些问题而受到惊恐发作，则可以将其投入使用。
感谢您的关注！