Clojure 的权衡以及如何减轻它们？

Question

本周初我与人交流，这个人决定停止使用 Clojure，我总结了他的观点。在我们拿起锄头追责任何一方之前，我更想知道如果你们同意他们的观点，我们能做些什么来减轻这些权衡。你尝试过什么？你的经验是什么？你的建议是什么？

我想声明我的目标不是批评任何人的工作。我爱 Clojure，我觉得这个人的见解激励我去了解 Clojure 的权衡，探索如何使用我们现有的工具来解决这个问题。

以下是这个人的问题的总结以及我的想法。

REPL 驱动的开发

• 感觉是对缓慢启动问题的一个折衷方案
• REPL 开发不高效。经常遇到需要重新启动的损坏的 REPL 状态。

Clojure

• 没有静态类型。
• 你怎么知道在 map 中有哪些键和值？

Spec

• 太啰嗦了。这似乎与 Clojure 通常所认可的简洁性相矛盾。
• 要从 spec 获取值需要大量的工作，需要你编写很多谓词、s/ 表单、检查器等...

我的想法

• CLJS 或 CLJ 的启动时间在我开发中并没有构成很大的障碍，GRAAL 可能是一个很好的解决方案。
• 我没有遇到那么多的 Clojure 损坏的 REPL 状态，但 CLJS 和 Shadow 中确实经常发生。我们能否利用像 Integrant 或 Component 这样的库来减轻这个问题？通常是什么导致不一致的状态？
• 至于静态类型，我可以理解为什么它是了解 map 内容的常用解决方案，但除了 spec，我们如何在代码中解决它？
• 自从与这个人交谈以来，我发现有很多时候我只是在 REPL 中执行代码，以找出我有什么数据。
• 我们应该给我们的函数添加更多文档来指定需要哪些键吗？我们能否更好地利用解构来强调预期的键？是否有更好的工具机制来帮助我们？
• 我自己对规范没有任何问题，但在这方面我并不是最有经验的。
• 我喜欢的是，你正在构建一个领域特定语言（DSL）来指定你的领域逻辑中的关系，这在我看来比静态类型更有优势，因为静态类型将所有问题都降低到了计算机科学的学术水平。
• 我真的需要知道这个我试图发送到我的市场中的供应商的引荐记录是记录类型吗？

你对此有什么看法？

Answer 1

两点简短的想法

1) 基于REPL的开发不仅仅是“解决启动速度慢的问题”，而是一种更好的软件开发和交互式方式。

在用REPL开发了一定程度的复杂性之后，回到没有REPL的系统（甚至是拥有好控制台的系统）感觉就像穿上混凝土靴子。

2) “你如何知道地图中的键和值？”- 通过REPL中检查它。！（开玩笑的。）

实际上，这里要提出的一个重要观点是测试。特别是在程序不同部分之间的边界上，自动测试可以缓和没有静态类型的一些缺点。如果测试证明一个程序部分在给定了正确的输入形状后将成功（如果不正确，则友好错误）的话，那么该部分的调用者可以自信地传递任何形状。

希望这能有所帮助。