在網路上看到這篇文章，我推薦每個軟體工程師都應該看一下這篇。雖然說有些觀點過於激進，不過大致上我是同意的。
為什麼軟體那麼「慢」？
在開頭當中，作者有提到，像是汽車、飛機、建築這些領域發展到現在，都已經有一定的模式在，飛機的翅膀、形狀設計、功能等等幾乎都是大同小異，而發展出來的成果也是有目共睹。
我最近也在思考，為什麼這些領域可以，但是在軟體開發上，事情好像越來越糟？每次跑 npm install 在 Macbook pro 或是 iMac 上都會聽到風扇全速旋轉的聲音，網頁開發好像構築在一個基底不穩的沙塔上，前端可以用的框架還有狀態管理工具就已經多到不勝枚舉。
不過拿軟體開發跟飛機之類的例子比較似乎有點不公平，飛機（以客機來說）設計的目的是為了讓乘客快速且安全地從 A 點到 B 點；房子是為了提供人們穩固且耐用的庇護所，這兩者都有相當明確的目的，也不太會因為時代演進而有不同目的。
但是在軟體上呢？因為迭代快速，所以也產生更多可能性，一個網頁最初的目的或許只是為了瀏覽資訊，但現在幾乎包山包海，看影片、聽音樂、發布動態、上傳圖片、玩遊戲，因為硬體的升級以及科技的進步，我們得以用單一個瀏覽器做到不同的事情。
另外說起來應該就是 JavaScript 的原罪了吧，一個在相當短的期間被製造出來的程式語言，到現在演變成全世界最熱門的程式語言，大概連作者自己都沒有想到。
用 Java 諷刺 JavaScript 我覺得還蠻不公平的，Java 有自己的 VM、Runtime、JDK 等等。在網頁開發上，我們只能依賴百家齊放的瀏覽器，也才造就了 Babel、Webpack 這些工具的出現。
從這個角度來看，似乎也不能這麼武斷的說：「硬體變快了，但軟體變慢了」，難道 20 年前有辦法光靠瀏覽器就能做到那麼多事嗎？難道 20 年前的軟體跟現在的軟體功能性及複雜度一樣嗎？
身為一個電腦的使用者，我們似乎還是需要一個極簡化的軟體，讓使用者在他們想要的時候，隨時可以用一個簡化後的瀏覽器（沒有歷史紀錄、下載檔案、devtool）給使用者們用。
作者也抱怨了現代網頁肥得要命，一個 gmail 竟然沒辦法滑順地滾動，slack 的 app 簡直是個資源怪獸。從這點來看，我自己也有點好奇，為什麼資源耗費那麼高，我知道背後是用 electron 實作，但為什麼用 electron 會讓資源消耗變那麼高呢？
我自己對 Electron 為 GUI 帶來的可能性是抱持著正向的態度，雖然也有不少人抱怨 Electron 相當吃資源，我覺得這也是未來應該要改善的事，但看看 Slack、看看 VS Code，都是在 Electron 下相當成功的案例。
作者繼續抱怨，來到文字編輯，他說 42 年前開發的 Emac 輸入文字的延遲都比現代的文字編輯器延遲小，3D 遊戲都可以在 16ms 之內渲染百萬計的圖形，為什麼簡單的文字編輯做不到？
雖然目前用的筆電好歹也是 Macbook Pro，但使用比較低階的使用者一定也是大有人在，我們的確不該因為自己正在使用比較好的配備，就樂觀地假設所有使用者也在使用，更不應該責怪使用者使用效能比較差的設備。這點毋庸置疑，看到 Slack 跟 VS Code 佔用的資源，我自己也嚇到了。
作者另外提到的一個問題：We’re stuck with it，這一段我是相當認同的。越來越多工程師並不怎麼在意一切是怎麼實現的，很慢？沒關係，反正已經完成業務要求；不懂怎麼運作？沒關係套件套一套就好。這些得過且過的心態不是一個專業工程師應該有得心態，這些不叫做工程化，而是懶惰。
最近也越來越體認到這一點，雖然現在的確有足夠多的工具，可以幫助你在一知半解的情況下建構一個還不錯的產品（網站），但對於細節的要求和原理，可以說是越來越不求甚解了，這對我來說不是個好現象，所以時常警惕自己要去理解背後的原理，大多數的時候並不難（雖然作業系統真的難 QQ）。
今年也打算好好回歸基礎，程式領域的三大浪漫：「作業系統、編譯和圖形學」，圖形學在 2017 年的時候學習 WebGL 已經被催殘一次了，剩下兩個領域作業系統跟編譯，大概就是今年最大的課題了吧。
