目标：如何让Haskell进入您的组织，以及如何通过更好的工程使您的组织更具生产力和盈利能力。
我在1.5年前与2018年LambdaConf上的人交谈后写下了这篇文章。我和一些人离线讨论过这个问题（至少……我想我已经讨论过了）。然后我很快就没有做任何其他事情。在2019年功能会议上与人们进行了一些对话后，我决定是时候复活并发布这个了。
如果我在这里分享的想法与你产生共鸣，并且你有兴趣进一步传播，请联系我（私下里很好，斯诺曼网络公司的迈克尔). 关于如何实现这一点，我还有其他更具体的想法，我将与线下的人分享。
感谢Functional Conf的每一位员工，他们给了我们前进的灵感和动力！
哈斯克尔在很多方面都是一种革命性的语言。今天广泛使用的许多语言都是对以前语言的增量更改。然而，哈斯克尔并不适合这种模式。诸如引用透明性、纯函数式编程、懒惰和不变性等概念与当今常见的编程方法截然不同。
大多数哈斯克勒（Haskeller）都会辩称，这些激进的改变是合理的，并带来了巨大的利益。与此同时，这种进行革命性变革的固有文化吸引了语言的某种思维方式。因此，我们最终陷入了这样一种情况，即Haskell基本上有两种不同（且重叠）的亚文化：
- 探索计算机科学、软件工程和数学中有趣且革命性的概念
- 制作更好的软件
同样，这些都是重叠的亚文化。哈斯克尔的整个历史就是这样一个案例：深奥的、学术的、智力的和“无用的”概念成为挑战性问题的优雅解决方案。Monad可能是这方面最突出的例子，我们看到许多其他语言正在慢慢采用这个概念来解决并发和错误处理方面的问题。
另一方面，并不是每个新概念都能转化为这些基本且有用的技术之一。即使对那些这样做的人来说：找到最实用的方法来利用这项技术也是一个费时费力的过程。
探索这些概念可以是有趣的、有益的、长期的，这对生产力有巨大的好处。然而，从短期和中期来看，这种勘探可能会导致较慢且不太可靠的结果。作为一家公司或项目经理评估Haskell的项目，这种不确定性可能会阻碍采用Haskell。
我们现在面临的情况是，Haskell经常被淘汰使用，这给双方带来了巨大的损失：
- 本可以从Haskell不太革命性的部分中实现生产力、可靠性和性能方面巨大好处的公司、项目和经理。相反，他们正在失去这种竞争优势。
- 那些更愿意在Haskell工作的工程师们——即使它的子公司不太革命性——也无法这样做，因为雇主担心会选择它。
我们希望改善这种情况。
无聊的哈斯克尔宣言
我们的主张很简单：对于许多软件工程案例，Haskell语言和生态系统的一个简单、定义明确的子集将为项目带来巨大价值，同时与其他选项相比，几乎没有风险。我们称这个子集为“无聊的哈斯克尔”，有点开玩笑。我们的目标是：
- 定义这样的子集
- 提供简单的文档、教程、食谱和库来鼓励这一子集
- 继续发展子集以优化其最佳实践
- 帮助感兴趣的工程师学习如何使用枯燥的Haskell，并在其公司中采用它
这方面最具体的步骤是创建里约图书馆，旨在捕捉这些原则。如果您今天想接受Boring Haskell，我们建议您使用该库。本文档的其余部分讨论了我们认为“无聊的哈斯克尔”，并激发了这些选择。
功率重量比
我们希望根据Haskell的功率重量比（也称为成本效益分析）来分析其特点。更直接地说：我们希望选择在最大限度降低成本的同时提供大量好处的功能。让我们举一些这两方面的例子：
权力/利益
- 更易于维护的代码
- 生产中的错误更少
- 更高的性能
- 更高的生产力
重量/成本
- 学习曲线
- 持续认知开销
- 正在进行的调整
- 编译时间变慢
- 性能不佳
功率重量比很大的东西的一个具体例子是求和类型。总和类型是一个需要解释的相对简单的概念。大多数人几乎可以立即摸索出这个概念。模式匹配感觉很自然。和类型解决了人们在编程任务中经常遇到的大量问题。
降低风险
本节充其量是草稿，请不要在此处阅读：）
我从业内人士那里听到的一个反复出现的主题是采用Haskell的风险。让我直接谈谈一些共同关注的问题：
如果我被卡住了，就没有可用的支持。Haskell有许多专门从事咨询服务的公司，他们能够提供帮助。我为其中一个工作.
我们找不到可雇佣的人。这是一个值得关注的问题；Haskell工程师总数较少。然而，您在Haskell中有一些很大的优势：
- 与大型语言相比，招聘方面的竞争较少。
- 喜欢哈斯克尔（Haskell）的人很有动力用它找工作。
- 如果你愿意远程招聘，有大量的候选人。
- 培训员工与Haskell合作是一种切实可行的选择。（这是我打算在未来进一步讨论的一个领域。）
如果我们只想继续编写Javascript，我不想投资学习Haskell。函数式编程原则功能强大，目前已被许多语言采用。学好它们的最好方法是学习像Haskell这样迫使你学习FP的语言。
我担心我会碰壁，哈斯克尔不会再工作了。这不是实践中的主要问题；人们编写的最常见的代码在纯Haskell中完全可以。然而：
- 如果由于库的可用性或类似原因，您需要使用其他语言，您可以随时与其他语言连接。即使我不是一个超级粉丝，微服务架构也会在这里发挥作用。
- 如果遇到性能问题，通常可以在Haskell中通过降低级别来解决。然而，Haskell中的FFI非常容易使用，所以调用C或Rust之类的东西非常容易。
- 如果你很难找到一种用函数风格解决问题的方法，你可以使用命令式Haskell。在Haskell中以完整的命令式风格编写，例如
IO（输入输出），可能不是惯用法，但它有效。正如SPJ所说（引用可能不准确），Haskell是世界上最好的祈使语言。
接下来的步骤
目前，我只是嗅出对这个一般性话题的兴趣。我有一些后续想法，但我宁愿在进一步讨论之前得到关于这个想法的反馈。保持联系，敬请期待！