怎麼實現我不管，這纔是我要的最好的計算機語言！

2019-05-19

今天把福川送的《Kotlin核心編程》掃完了，正好也想借這個機會，順道聊聊自己對計算機語言的預期和喜好。

首先說說寫這本書的作者團隊，從書裏的言辭和內容中也能看出，這個團隊在Java，Scala和Kotlin生態裏都有涉獵，應該是從Scala轉Kotlin的，所以能夠對ADT， Higher-Kinder Functions， Type Theory等理論都能夠如數家珍，至於Actor-based Concurrency， 那當然更是今天Scala生態的Akka莫屬了。

整本書雖然我讀起來很順，但我覺得不一定適合新手，如果你之前對Scala語言和生態有涉獵，那麼，自然可以做到“曾經滄海難爲水”了，因爲很多Kotlin的語言特性跟Scala真的很像，甚至可以直接按照Scala的知覺寫代碼， 比如類型後置，比如String Interpolation， 比如val/var， 應該說， Kotlin勝在語言的設計初衷： 兼容Java，實用主義 ， 這其實是Scala那幫SB社區Leaders永遠趕不上的（雖然我一直是Scala粉兒，但我該罵還是要罵）， 但是， 理想是美好的， 現實是殘酷的，從我的角度來看，Kotlin語言還是無法滿足我對一門理想的計算機語言的預期， 因爲現在很多的計算機語言設計者根本就沒有把計算機語言當一個產品來做，一個好的產品首先就應該是簡單，別搞那麼多烏七八糟的語法和語法糖，別搞那麼多亂七八糟的理論和tricky的技巧，寫了tmd這麼些年代碼，你我都應該明白， 所有的奇技淫巧，都抵不過大巧若拙， 所有的語言爭吵，都抵不過老子什麼最熟就擼哪個。

Kotlin雖然有簡單的一面，但我也看到了很多不那麼簡單一隅， data class X | annotation class X | enum class X | sealed class X , 這些我認爲是好的設計，因爲從語法到語義直覺上都是一致的，所以簡單， 但像enum裏面定義複雜邏輯， 語法糖一大堆， lazy/lateinit, companion object, extends針對interface和class不一致， pattern match更是二流角色，所有這些，我覺得都是值得詬病的， 詬病的背後就是：

如果一門計算機語音就是一個產品， 開發人員就是使用產品的人，對於使用產品的人來講， Don’t Make Me Think纔是直接訴求， 你跟我抱怨實現有限制， 實現背景有什麼意義呢？ 換句話說，難道還是你自己對自己的產品和實現的把控能力不行嗎？這其實跟公司裏很多開發抱怨說產品經理拋給他們的永遠是一句“怎麼實現我不管”不是一個道理嗎？ 從用戶的角度來說，產品經理說的難道不對嗎？ 怎麼實現就是你研發的事情啊？

對一門計算機語音的設計者來說也是一個道理， 語言難用，學習曲線高，說到底都是你這個產品經理的問題， 要麼是產品設計有問題，要麼你團隊的能力有問題，起碼對問題域和編譯器原理和工程都把控不足。

但話又說回來了， 現實其實就是這麼不完美， 每一門語言就像每一個人一樣，有好的一面，也有不好的一面， 當現實沒法改變的時候，我們就得挑各個實體好的那些面來用：

• 語言上， Kotlin默認的String Interpolation, 默認的.java <-> .kotlin的轉換等微小的細節都是用戶體驗很好的點兒，而Scala裏則需要通過語法上或者類庫上特定的明確指示才能達成；
• 架構上， 爲什麼我在《SpringBoot揭祕》裏講得東西都很簡單，基本上只是談了SpringBoot的內核和一些簡單的產品思路，因爲我要傳達的不是什麼技術牛逼，而是說你能夠在各個生態間遊獵之後，對各個方案進行裁剪，使之能夠以更低的成本(包含大多數人的認知成本)、更高的效率形成用戶可用的產品， 這個纔是牛逼的能力，技術你自己覺得多麼精深沒意義，形成產品，爲用戶創造價值纔有意義。
• 用人上，尺有所短寸有所長，每個人都有優點和缺點， CTO可以寫代碼，但寫代碼絕對不是CTO的核心能力，爲什麼馮大輝在丁香園的經歷會成爲他自嘲的一個案例(就跟我自嘲自己是曾經的運維架構師一樣)，因爲CTO每個公司就那麼一個， 大部分人是沒做過甚至做不了CTO的，所以他們更願意以自己的認知來評判CTO，殊不知自己其實跟田間地頭說當了皇帝要搞兩個金鋤頭的農民一樣，《見識》很重要。 CTO的核心能力之一其實是識人用人，讓每個人的優勢發揮出來，把每個人“裁剪”後組織成一個有蓬勃的戰鬥力、有鮮明的技術文化、能夠持續高效的支撐公司產品和業務發展的技術團隊， 這纔是CTO的硬核。

我們需要精英，但我們不需要僞精英，真正的精英是能夠通過機制、手段和教育將大多數非經營的人組織起來成事，即那種“料民力則無事不成”的人，而不是那些高舉精深的概念和不實用的複雜技術吹噓炫耀的人， 從語言的設計者羣體來講， Scala就屬於後者，Golang/Kotlin顯然更追求實用和拿結果。

Keep It Simple, Stupid, easier said than done！