寫這篇文章的起意是看一位博主寫的年終總結，談到他學習go語言及其程式設計哲學。這讓我突然意識到，最近一直覺得自己寫python寫的很不舒服，總覺得這門語言有很多弊病。現在看來，是因為我忘了這門語言的設計哲學了。
python本身就是以優雅著稱，**本來就是要易看易讀。儘管這門語言被用於很多領域，但這也是因為他的「優雅」而讓人喜歡和使用。正如「二八定律」所指，讓人詬病的python效能不佳其實在大多數使用python進行邏輯實現的時候，效能都不是他們要解決的問題。而對於需要嚴格處理效能問題的專案，從一開始的技術棧就會放棄python了。所以，同樣的，對python進行效能調優並不是不需要，但是當這是乙個嚴重影響業務的問題的時候，就應該想到，整個專案選擇python是否合理。總而言之，python是有自己的設計哲學的，其他語言也是，在使用一門語言進行編碼的時候，就應該考慮到這一些。
同樣的，談python的動態型別（也是效能差的原因之一）也是debug的乙個難題。很多人認為很多大廠在使用python做各種後台服務或其他業務應用的開發語言，即是表示python好用，而自己使用進行dev和debug的時候則有各種坑，所以覺得他本質不好。其實除了大廠有專門的團隊進行語言修飾（各種內部使用的包）及嚴格的語言規範和**審查外，最重要的是，我們在使用python做業務開發的時候，是否「優雅」。因為python可以作為指令碼語言，我們是否一不小心就把乙個業務邏輯寫成乙個指令碼，跑通即算完成？
所以，認為python不好的，應該去讀一讀《程式設計師的職業修養》。畢竟python才是最好的語言。
後續有機會再談各語言的設計哲學，畢竟這需要豐富實踐，我還是才疏學淺。之所以加上吐槽的字首，就是怕誤人子弟。最近看很多文章，點進去讀才發現都是我不關心的或者是copy-paste的或者是點到即止的。但是這些文章標題都寫的很「認真」。為了避免讓人點進來後失望，加乙個吐槽做標示。也聊表歉意。
golang 吐槽multipart的設計
最近在做郵件解析的工作，因此接觸到multipart庫，用了之後才發現golang的multipart有一點設計很詭異。紅線標出來的話意思是 當content transfer encoding的值為quoted printable時，該header將會在map中隱藏，而且，當呼叫part read...
golang 吐槽multipart的設計
最近在做郵件解析的工作，因此接觸到multipart庫，用了之後才發現golang的multipart有一點設計很詭異。紅線標出來的話意思是 當content transfer encoding的值為quoted printable時，該header將會在map中隱藏，而且，當呼叫part read...
網路程式設計課設吐槽記錄
運用子執行緒來實現全雙工通訊 service端 void sendinfo socket sockconn if strcmp gets s s,50 quit 0 sprintf s sendbuf,s send sockconn,sendbuf,strlen sendbuf 1 0 傳送訊息 清...