為什麼 Clojure 這麼好，卻沒有流行起來？
釐清客戶的衡量標準，是對企業銷售的關鍵
從我第一天開始寫 Clojure 語言開始，已經過了八年，而台灣 Clojure 社群的大小，只論人數的話，沒有什麼大的成長。( 只論百分比的話，還是有些成長。) 相比之下，Kotlin 社群卻成長飛快，在很短的時間之內，社群就從無到有，並且大幅超越 Clojure 。
應該很多 Clojure Programmer 都常常問自己，「為什麼 Clojure 帶來的生產力這麼高，卻沒有流行起來？」
關於這個問題的答案，網路上找得到的論點，我常看到的主要論點有 2 項：
轉換成本高，因為光是連學習的門檻都很高。在一間企業有技術棧決策權的高層，很可能因為學習門檻，難以了解它，也因此就算有基層的工程師想要採用，也無法推動。
成效難以評估，且沒有對應的殺手級應用。殺手級應用是指，某件要解決的問題，剛好有某個軟體就是該問題的最佳解法。有殺手級應用的話，Clojure 帶來的成效就很容易彰顯。
針對上述的第二個論點，我的思考是，如果我可以用什麼方式向客戶解釋它的效益，就有機會推廣。比方說，我會講，Clojure 可以帶來約五倍的生產力，如果對話還可以繼續，那我也許可以設法解釋衡量的標準。
然而，我過去的實驗並不太成功。該怎麼解釋這個不成功呢？
最近在一篇文章裡， Nathan Marz 提出了他的論點，似乎解釋了我的失敗。
這裡似乎存在著一個矛盾——如果 Clojure 能夠實現如此高的生產力提升，那麼為什麼它仍然是產業中的小眾語言？為什麼使用 Clojure 的人並沒有徹底擊敗競爭對手，以至於現在每個程式設計師都爭先恐後地採用 Clojure 來平衡競爭環境？
我相信這只是因為 Clojure 還沒有解決軟體開發的所有方面。這並不是對 Clojure 的批評，而是對其改善範圍的清楚認知。持久性資料儲存、部署、監控、隨著時間的推移不斷發展應用程式的狀態和邏輯、容錯和可擴展等都是建立完整的軟體的巨大成本。使用資料庫時，Clojure 的原則常常會被破壞，因為資料庫迫使你圍繞其資料模型和功能來調整程式碼。
如果 Nathan Marz 的論點為真的話，那很可能之前當客戶聽我說，改變程式語言可以為他們帶來生產力的提昇時，第一時間就已經在心裡說「不」。原因是因為，就他們對軟體開發現狀的理解，問題的根源並不是出在程式語言，而是出在分散式系統、資料庫、布署、可擴展等議題。換言之，我的客戶在第一時間所做出的成效衡量 (measurement of results) ，就已經認定我的論點不適用於他們。
如果是這樣子的話，那我要改變策略，日後要直接談 Datomic 、談最適合搭配 Clojure 應用的資料庫，它讓你在採用的第一天，就做到事件溯源 (event sourcing) 與時間旅行資料庫查詢 (time travel query)。