[譯]使用Haskell創業4年的感覺

我想說的：
最近在學習Haskell語言,這是一門函數式編程語言。不少人都在問我爲何學它，問我學會這門語言能作什麼，問我這門語言的市場佔有率怎麼樣。

其實，站在一個初學者的角度，我沒有辦法很好的回答這些問題。我一開始去學習這門語言，只是想去了解函數式編程這種與以前所學的、所用的編程方式徹底不一樣的編程思惟。你問我學會了能作什麼，呵呵，多學點東西又不會死。
當別人問我這些問題的時候，我也在問我本身。面對難度如此高的語言，我也會想去逃避。我在不停的懷疑，本身這樣去學習是否真的有意義。
這個時候，就須要來點雞湯啦 ---- 有效行動的邏輯
在有效行動者的世界裏面，他永遠相信兩件事：
第一，先幹了再說，由於只要幹了，我就會遇到更多的意外，就有機會把握這些意外。
第二，只要我行動，就有機會洞察優點背後的代價，有機會把那些壞事變成好事。
總結一下就是，若是有件事可幹可不幹，時間容許的狀況下，那就去幹。
翻譯這篇文章，也只是想讓更多的人瞭解Haskell這門語言，同時也堅決本身的信念，繼續學習下去。

原文連接：http://baatz.io/posts/haskell...

下面是正文：

2012年，我和個人合夥人共同創辦了一家公司----Better，一家新型的面向企業的線上學習平臺。 咱們的目標是讓大公司更快、更便宜地開發，提供適應性，跨平臺，多語言的在線課程。

從第一天起，咱們就決定使用Haskell做爲咱們的主要開發語言，直到咱們的團隊已經擴展到了10個開發人員，它仍然是咱們在後端使用的惟一語言。

通過一段時間的試驗和開發，Better在幾個月的時間裏，常常性收入從0美圓增加到了500K+，客戶包括了美國運通和Swissport等大型企業。然而，分佈式的模式被證實是更有效的解決方案，咱們最終出售給GRC Solutions，一家澳大利亞的合規公司。

儘管你們對Haskell的興趣彷佛在不停的增加，但它在生產環境中的使用仍然少之又少。有些人甚至錯誤的認爲這只是一門學術語言，別的什麼都作不了。在這篇文章中，我想告訴你們我對項目中使用Haskell的一些見解。你能用它完成項目麼？它能在實踐中保持穩定麼？你能招到相應的開發人員麼？是否更多的公司應該使用它？

我對上面問題的回答是YES。這可能不會適用於全部的問題或者全部的團隊，但這樣作絕對值得考慮。對於構建服務端，Haskell多是你如今所能找到的最接近祕密武器的東西。

爲何咱們選擇Haskell？

在建立Better幾年前，我爲一家財務顧問公司開發了一個預測模型。第一款原型是使用Python開發的，結果這個模型很脆弱並且老是會出錯。我該如何確保變量的類型不會改變？我該如何避免函數中某個值發生突變？我須要花不少時間去寫大量的測試用例，才能保證程序不出錯。

我回想起了大學時學過的Haskell。用Haskell作了幾天的實驗以後，我驚訝的發現，Haskell彷佛更適合這個任務。工做了一週以後，我獲得了一個粗糙版本的預測模型。後來，當咱們開始創辦Batter時，我相信Haskell會比其餘經常使用的語言更有效率。

Haskell擁有純淨、惰性、靜態強類型和類型推斷等特性，這些特性讓它跟別的語言區分開來。純淨而沒有反作用，讓開發者更容易查找程序中存在的問題。惰性讓咱們更好進行函數組合和性能優化（以更難以理解的存儲開銷爲代價）。靜態強類型和類型推斷機制，保證了程序的一致性，讓重構更快樂，順手消除了一大波bug，還不用編寫和維護測試用例。把這些特性疊加在一塊兒，絕對是一種愉快並且高效的開發體驗。

使用Haskell能把事情辦好麼？

若是你從頭開始構建項目，Haskell徹底可以讓你用至關有限的知識完成工做。用Haskell寫的代碼可能不會特別整潔和高效。可是最終你會發現，僅僅使用5行代碼，就能夠創建一個標準的能夠被不斷重用的抽象。

對有經驗的開發者來講，提升Haskell的運行效率是一個不小的挑戰。這對新手來講實在是太不友好了，爲了提升效率，你每每須要學習不少東西。Haskell十分重視概念和抽象，不少Haskell中的概念只是名字看上去比較嚇人，其實很好理解。學習Haskell時，能夠參考一些教科書，可是不少博客和論文也具備很重要的學習價值。Haskell不可能符合全部人的胃口，但其中思想的價值遠超語言自己。若是經過學習Haskell，可以影響你在編寫程序時的思惟方式，那麼目的就達到了。

在實際的使用中，咱們對Haskell最大的抱怨之一是基本的工具支持。使用cabal-install構建項目太不順利了。以後出現的Stack卻是減小了這方面的槽點。Stack對初學者來講是十分友好的，它讓大型Haskell項目的管理更加方便。你能夠作許多其餘工具鏈方面的標準，像github上面的fork庫，依賴fork庫就沒必要再發布包了。

Haskell的工具支持徹底沒有達到它應該有的樣子，特別是在IDE和編輯器的支持上。可能存在各類不一樣的集成開發環境，並且目前來看仍是十分混亂的，沒有一個通用的標準。對Haskell如此豐富並且有用的類型信息來講，這簡直是個恥辱。

若是談到各類各樣的庫，它們的覆蓋面雖然不是很大，但仍是足夠使用的。咱們也用Haskell寫了一些比較粗糙的內部庫（好比經過Mandrill的API發送郵件）。Haskell一樣也有些很出名的庫，可是去肯定使用哪一個更好並不容易，並且質量差別也很大。若是不算內存出現的問題的話，咱們只遇到過一個嚴重的庫錯誤，這個bug致使沒法進行https鏈接。

至於語言自己，Haskell的惰性要求使用者考慮更多的空間複雜度。實際上是有很好的工具和技術可以幫助開發者作到這一點的。你固然能夠編寫節省空間的代碼，但這須要你有意識的去作這些事情。至於語言自己，Haskell的惰性計算須要你考慮更多的空間複雜性。有很好的工具和技術來幫助解決這個問題，你固然能夠編寫節省空間的代碼，但它須要比使用嚴格的語言更有意識的努力。 也許你會經過使用更好和更強大的抽象來回收這種心理負荷。 還有一些其餘小麻煩，如字符串類型之間的轉換，標準風格的缺少，沒有良好的記錄語法。Lenses確實解決了記錄的問題，可是這東西很差調試，並且須要花不少時間學習。

在平常使用中，Haskell實際上是特別務實的。最關鍵的一點，我認爲很難找到一個Haskell代碼庫有值得重構的點。類型推斷系統和純度可以在你閱讀代碼尋找bug時給你更多的信心。

Better在經歷了幾回推到重寫以後，仍是放棄了建立一個偉大軟件的雄心壯志。儘管咱們對市場的判斷老是出錯，工程團隊卻從未失敗過。

軟件穩定麼？

Batter平臺每週大約會產生50萬次的用戶學習行爲，它已經運行了一年多，沒有停機，也沒有維護。咱們至今尚未找到任何bug。到最後，在中止平臺的開發以前，咱們作了一次重大的重構。

我只是舉些例子來當證據，軟件運行的那麼穩定讓我也感到很驚訝。 咱們有一個偉大的工程師團隊，他們值得信任，我也一樣信任Haskell。 咱們沒有使用測試驅動開發，咱們僅僅針對關鍵部分進行了測試。 這彷佛是正確的成本/質量權衡方式。若是你如今問我，我仍然會這麼作。

Haskell的類型推斷系統使開發者沒必要像在弱類型語言中那樣，須要寫一堆的測試用例來捕獲不一致。 具備類型推斷系統，能夠減小編寫和維護測試用例帶來的成本。我認爲，測試驅動開發的論點不只僅是編寫測試來捕捉bug， 它一樣有助於開發人員更清楚地思考問題。 然而，Haskell的純淨和類型比測試驅動開發這種方式強有力多了。「一旦編譯經過，它就能工做」，這句話可不是個玩笑哦。

我可不是說測試不重要，相反，測試實際上是至關重要的。 類型系統可以保證類型的一致性，可是一致的程序也能夠作錯事。測試是迭代速度和質量之間的折衷， 不一樣的業務須要不一樣的權衡。

Haskell也有方便你作測試的優秀工具。 例如，QuickCheck能夠基於工程師所指定的程序應該保持的屬性，來自動生成大量的隨機測試用例（利用Haskell的類型系統）。

所以，Haskell彷佛特別適合用於對軟件的正確性和質量要求較高的項目中。 你可能指望以減小迭代速度爲代價保證它的安全性，但有趣的是，你將會發現本身的迭代速度遠比比使用弱類型，非純淨語言更快。

你能僱到寫Haskell的人麼？

Better這個項目是在蘇黎世進行的。咱們剛開始進行時，不知道這裏有誰會使用Haskell，可是招聘開發人員比咱們預想的要容易的多，這很大程度上都要歸功於Haskell。找到合適的開發者仍是須要花一些力氣的，但咱們的經驗是，不少來面試的開發人員得知可以用Haskell開發項目時都表現的很興奮。咱們終結了一個偉大的團隊，其中幾我的是從國外搬到蘇黎世與咱們合做的。很早的時候咱們就決定公司不走遠程開發的模式，但若是您的團隊願意接受遠程開發，您應該會有更多的可供選擇的機會。

咱們根據咱們本身的需求，將技術，興趣和動機這些條件混合起來做爲招人的標準，根據這些標準咱們招到了幾個技術很棒的Haskellers。咱們固然僱傭過只有一些Haskell基礎的人。咱們的一位開發人員是直接從物理學學位過來的，在生產環境的指導下迅速成爲了經驗豐富的開發人員。

雖然咱們的薪資水平不能與Google，IBM蘇黎世研究院或本地的大型銀行相提並論，但咱們仍然能吸引到優秀的人才。使用Haskell是咱們能作到這一點的緣由之一 ---- 好的開發人員傾向於使用更好的技術。

它對公司的文化有什麼影響麼？

很難將編程語言對工程師文化，僱傭決策，管理風格和我的特性的影響分離開來，所以咱們的工程師文化是深受Haskell影響的。

人們不會爲了高薪而學習Haskell。市面上並無足夠的須要Haskell的工做。這種語言也比其餘語言更難學習，這會過濾掉那些不肯意努力學習有趣的東西如functors，applicatives和monads的人。

這樣作的好處是，若是你僱傭的人花了一點時間學習了Haskell，他們可能會比日常人更有內在動機來編寫代碼和學習新東西。缺點是他們頗有可能厭惡工做，由於工做是在浪費和減小學習的機會。

所以，我認爲選擇Haskell有助於創建咱們想要的工程師文化，但它不是魔法 ---- 咱們也花了很大的力氣去招聘，咱們試圖作的更加公平，咱們尋找那些可以駕馭各類語言的開發者。

那麼，你應該使用Haskell嗎？

Haskell並不適合全部人。它不一樣於大多數開發人員的習慣。它須要學習各類很抽象的概念。它的生態系統不像如今流行的那些語言那麼成熟。它不是最快的語言，黑客一塊兒快速開發原型也須要2天。它有垃圾收集，所以它不適合實時系統。它的空間複雜度老是變幻莫測的。擁有Haskell生產經驗的人少之又少。

但若是缺點不會破壞你的面試，你可能會獲得一個很棒的待遇。 Haskell適合在小型的，技術熟練的和不斷成長的團隊中使用。隨着你的代碼庫的擴展和發展，Haskell處理複雜性，澄清思惟和確保一致性的能力是一個福音。 你不用擔憂服務器會崩潰這種問題，放心去睡大覺就好啦。你不須要花不少時間在舊代碼中尋找bug。你可以至關自信、敏捷地重構。在招聘時，你也會從Java，Node和Ruby等等市場中脫穎而出。你會開始在全新的抽象方式中考慮如何構建程序。誰知道呢，你甚至會十分享受你的工做呢。

若是回頭從新去過在Better的那幾年，不少事情我也許會作不一樣的選擇，可是選擇Haskell做爲主要的開發語言這一點，我始終不會改變。