选择Haskell并不是良好软件设计的代名词

互联网上存在一个普遍存在的谬论，并引起了足够的混乱，因此可以澄清一下：团队决定成为“ Haskell商店”，雇用最大的俄罗斯方块功能，因此期望直接暗示并默认产生出色的软件。换个说法是为了更清楚：Haskell或与此相关的任何其他特定语言，不会自动解决与软件生产中的体系结构和宏级别决策相关的所有问题。相信否则可能会比选择一种主流语言（例如JavaScript）并处理其疣实际上产生更糟糕的结果。

这里有一些示例，其中仅“选择Haskell”根本无法自动为您解决问题：

在软件开发中，尤其是在小组设置中，放下，交流和体现正确的价值层次

想象一下您的软件应该具有的正确MVP功能，使其与从那里获得的持续增强保持一致

知道在每一个小问题上都花了大笔钱会阻碍进步，甚至在非常MVP的情况下也需要深切照顾

选择合适的数据库-知道何时适当地结合使用Postgres，Redis，DynamoDb，ElasticSearch等

知道何时进行300毫秒的数据库调用就可以了，甚至50毫秒的时间也不知道。

知道何时使用外部异步队列，它们的局限性，缺点等，以及何时仅以内联方式完成一些工作 找出正确的数据库架构（即使使用NoSQL，也要记住总有一个架构） 对您的功能（特别是那些进行外部调用，IO等的功能）实施适当的容错能力。 拥有良好的结构化日志记录做法，相反-知道什么时候日志过多会损害系统 增强代码库的清晰度-不太冗余，也不会过早抽象 找出一种在团队环境中实现解决方案迭代增长的方法（通常一个人很容易，甚至五个人也很难） 知道何时为长期正确性而优化编码风格（即类型俄罗斯方块及其带来的所有噪声）以及何时为简化逻辑表达而进行优化

从所关注的学术领域来看，Haskell生态系统的从业人员可能比典型的更大。这是我们社区的一项特殊优势，但这通常也意味着我们更多的讨论都集中在诸如高级类型系统之类的话题上，而不是例如针对各种用例应该有一个不错的基准应用程序体系结构。我们必须不断提醒自己，后者实际上对实用软件更重要-基线Haskell2010已经为您提供了出色的工具包，但是错误地选择上述选项可能会破坏您的项目。

需要明确的是，选择Haskell的商业团队通常这样做是因为他们相信Haskell将提供一个良好的语法/语言/编码环境，从而使自下而上地将团队偏向积极的方向。然而，我们所有人都听说过战斗故事，其中将商业努力的失败后来部分归咎于基础技术/语言（例如Haskell）的选择。在我的评估中，根本原因通常不是语言，而是系统体系结构，开发准则，团队范围内的价值观（我可能稍后再说更多）和其他类似“宏”主题中做出的错误选择。

Haskell是一个不错的选择，我们社区中的许多人都非常喜欢它（包括我自己），但是您仍然需要正确处理所有其他事情。放弃您对良好软件治理的责任，因为您“选择了Haskell，因此一切都已解决”。

非常感谢Ryan Trinkle，Doug Beardsley，David Drake和Michael Xavier对本文的早期草稿提供了反馈。