檢討和一些對C的新看法

我不應該在這個部落格裡說無關的事情，其實我真正的動機是保證發文章的頻率。我對技術以外的事情，除了一些愚蠢的人類的慾望和心裡反應還在，其實理智上是早已放棄的。

最近研發工作很不順利，就越發關注不相干的事情；結果效率就越低。這真是太墮落了。隨著年齡的變大，未來精力肯定會衰退，以我的目標而言，在這麼耽誤時間是絕對要不得的。

即便以這個部落格本來可以對其他人的價值而言，我也太浪費了。沒得說就不發文章就好了，何必去提那些根本不值得關心的事情。大家來和我交流也不是為了這些垃圾事情。

以後基本上唯寫我自己技術上的總結。我應該變成一個純純粹粹的技術人，最多再加上對技術修鍊如何提升自身社會價值的思考。包括自身狀態上，拋棄掉無用的東西，輕裝上陣。

--------

最近一個實踐的小技巧是：幾行代碼的實現了一個利用C++ lambda的資源管理對象（省得寫free/delete的同時，防止異常帶來的資源泄漏），比老的方法又少了些繁文縟節；推薦。另一個感受是C/C++還是不夠靈活，即便是只看純C其語言本身的假設也太多。

從這個角度看，原來被灌輸的“C不是進階語言”的看法就不那麼成立了。它並不像想象中那樣貼近機器/系統本身的模型，而只是自動化管理的機制和其它東西較少，多放了一些權罷了。記憶體配置的方式是一個例子。一個問題是選擇限制為兩個：函數簽名中暴露外部不關心的細節以利用棧（說穿了是已經開好的並由運行時管理的一塊記憶體），或者開在堆裡給外部一個指標（抽象的說就是引用了）。

這表面上看起來是個取捨問題：提供機制越多越方便，同時承受代價。但深層次的看事情未必這麼簡單。我覺得這些語言自動化機制本身是不可定製的，這才是根源所在。比如上面他提到的資源管理的小技巧，它本身是一些語言提供特性的組合，這是一種可配置性；但更根本的，這些語言特性本身卻是死的。這個有用加這個、那個有用加那個，一個機制中正面負面還都得照單全收，什麼時候才是個頭呢？

元編程的概念還應該繼續深化，並且如果提供元編程的特性，它應該至少在一些關鍵性的地方可以自我配置，且它的工作層面應該完全貼合在更底層的硬體/系統模型之上，更好的是只表達底層模型的知識和它們形成的限制與模式。編程應該變成純粹的新知識表達、已有知識重複利用的過程而盡量減少其它限制。比如現有自動化機制給的，是“已有知識重複利用”；如果這個現有的不是最貼切的，應該可以讓程式員自行安排並被其它人利用。

產生這些想法的根源在於，我個人工作中總是存在著選擇上的搖擺。A也是雞肋、B也是雞肋；兩個雞肋中選擇最好的一個，需要的各種考慮其量卻是巨大的。相比讓使用者自己創造（雖然也要花費大量時間），這是完完全全的浪費。

說白了繼承我原來的思路，不但物件導向一類的高層次方法論映射到語言具體設計中是毫無必要的、過程抽象的當前這種具體實現也是（當然函數式也跑不了）。這些軟體構建方法的甜頭歸根結蒂在於提供各種模子，在不存在物理限制的領域這太落後了（都這樣是reasonable的，但未必仍舊是合理的）。

其實現代軟體開發的這種瓶頸，觀察C++的話是再明顯不過的。從語言設計的所謂“演化”、到STL庫的各種設計，複雜性成快速增長；但這種增長卻並未很好的切合使用者需求。比如我曾考慮結合allocator定製和placement new解決std::vector安放在記憶體什麼地方的問題，可是這個方案也太蹩腳了一些，也還存在種種限制。

真正的程式員（不考慮單純用現有技術完成需求的開發人員）必須從這種種桎梏中解放出來，軟體品質的提高才有指望。看看這些垃圾的軟體吧，從作業系統到外殼到應用軟體，本來一切都該更好的。更不要提那該死的火星探測器了。