这是一篇2014年的文章，主要针对FP和OOP混合，主要部分是函数编程，但又不是纯粹的函数式编程，例如Scala，原文点击标题。
大概意思是：软件行业有一种趋势是出售近乎函数式编程作为解决开发人员面临的并发性，并行性（多核），当然还有大数据的问题的灵丹妙药。不幸的是，正如“突出安全”不起作用，“突出函数”也不起作用。相反，开发人员也应该认真考虑一个完全原教旨主义的选项：拥抱纯粹的懒惰函数式编程，并使用monad在类型系统中明确表现出所有效果。
许多人都在吹嘘“近乎函数性的编程”和“有限的副作用”，作为对抗室内新大象的完美武器：并发性和并行性。很少有人愿意接受这些好处必然会以牺牲I / O等常见操作中的潜在影响的便利性为代价，正如节食者宁愿不承认锻炼的好处必然以牺牲时间和汗水为代价。
“近乎函数式编程”的想法是不可行的。通过仅部分消除隐含的副作用，使命令式编程语言更安全是不可能的。留下一种效果通常足以模拟你刚试图去除的效果。另一方面，允许在纯语言中“忘记”效果也会以自己的方式造成混乱。
不幸的是，没有黄金中间，我们面临着一个经典的二分法，只能两者选择其一。
(从一开始Scala语言的设计就是允许FP和OOP两者正交，但在实践中它并没有那么好用。要么人们使用它作为OOP和更好的Java，要么将它用作纯FP语言。)
(也有人认为：混合FP和OO架构对我来说很有意义。FP对于某些事情来说真的很棒，但是当你必须通过可变状态设备的外部世界产生效果时，为什么不把它交给OO中的基础设施代码呢？这是一种成熟，无偏见的方法。
但是最后，必须以某种方式管理副作用。因为最终没有副作用的程序根本没用。无论是OO还是FP，将副作用推向应用程序的边界都是好的。
Haskell强制使用IO monad并且得到了编译器的帮助，但在OOP中你可以使用类似六边形体系结构的东西，它允许在应用程序体系结构边界的适配器中包含外部世界的副作用。这非常相似)