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中执行操作，只是为了找出我有什么数据。
• 我们应该在我们的函数中添加更多文档来指定所需的键吗？我们能否更好地利用解构来强调预期的键？是否有更好的工具机制来帮助这个？
• 我自己对spec没有任何问题，但我并不是最擅长它。
• 我喜欢的是，你正在构建一个领域特定语言（DSL）来指定你的领域逻辑中的关系，这对我来说似乎比静态类型更具有优势，因为静态类型会将所有问题都降低到计算机科学的学术水平。
• 我真的需要知道这个我试图发送给市场中的供应商的潜在客户是一个记录类型吗？

你怎么看？

Answer 1

两个简短的想法

1) REPL驱动的开发不仅仅是“解决启动缓慢问题的权宜之计”，更是“一种更好的软件开发交互式方式”。

在REPL中开发出一定的技巧之后，回到没有REPL的系统（即使是拥有良好控制台的系统），感觉就像穿上了水泥靴。

2) “你怎么知道一个映射中包含哪些键和值？” - 通过在REPL中检查它。（！）我是开玩笑的。

事实上，这里需要提出的一个重要问题是测试。自动化测试，特别是在程序各个部分之间的边界上，可以缓解没有静态类型的一些缺点。如果测试证明程序的某个部分在给出正确输入形状的情况下将会成功执行（如果不能则优雅地出错），那么调用该部分的调用者可以自信地传递任何形状。

希望这有助于。