技術棧語言選型要考慮語言本身的設計哲學
寫這篇文章的起意是看一位博主寫的年終總結，談到他學習go語言及其編程哲學。這讓我突然意識到，最近一直覺得自己寫python寫的很不舒服，總覺得這門語言有很多弊病。現在看來，是因爲我忘了這門語言的設計哲學了。
python本身就是以優雅著稱，代碼本來就是要易看易讀。儘管這門語言被用於很多領域，但這也是因爲他的“優雅”而讓人喜歡和使用。正如“二八定律”所指，讓人詬病的python性能不佳其實在大多數使用python進行邏輯實現的時候，性能都不是他們要解決的問題。而對於需要嚴格處理性能問題的項目，從一開始的技術棧就會放棄python了。所以，同樣的，對python進行性能調優並不是不需要，但是當這是一個嚴重影響業務的問題的時候，就應該想到，整個項目選擇python是否合理。總而言之，python是有自己的設計哲學的，其他語言也是，在使用一門語言進行編碼的時候，就應該考慮到這一些。
python本身沒有錯
同樣的，談python的動態類型（也是性能差的原因之一）也是debug的一個難題。很多人認爲很多大廠在使用python做各種後臺服務或其他業務應用的開發語言，即是表示python好用，而自己使用進行dev和debug的時候則有各種坑，所以覺得他本質不好。其實除了大廠有專門的團隊進行語言修飾（各種內部使用的包）及嚴格的語言規範和代碼審查外，最重要的是，我們在使用python做業務開發的時候，是否“優雅”。因爲python可以作爲腳本語言，我們是否一不小心就把一個業務邏輯寫成一個腳本，跑通即算完成？
所以，認爲python不好的，應該去讀一讀《程序員的職業修養》。畢竟python纔是最好的語言。
最後（僞）
後續有機會再談各語言的設計哲學，畢竟這需要豐富實踐，我還是才疏學淺。之所以加上吐槽的前綴，就是怕誤人子弟。最近看很多文章，點進去讀才發現都是我不關心的或者是copy-paste的或者是點到即止的。但是這些文章標題都寫的很“認真”。爲了避免讓人點進來後失望，加一個吐槽做標示。也聊表歉意。