canonical

不知道你那個Witrix，，商業上發展得如何。

我曾參與創建過一個屬于找死型的國內做通用開發工具的公司。雖然后來痛感國內通用軟件市場的腐爛轉而做起了電子行業，不過關于開發工具和語言的思考一直沒有停止。

和這里的人相比，我對現在這些新的語言和發展有些隔膜了，不過很多東西由于能和我的思考對應上，雖然缺少實踐也能理解一二。

在你的文章中看到了不少同感，嘗試做點交流，雖然很難互相理解，但我可以嘗試表達一下：

1 受到認識論的一些啟發，我想我們首先應該將軟件開發的過程定義為一個科學發現的過程，一個通過理性分析建構邏輯模型的過程，是在理論-事實的迭代中逐漸完善的。這一點已經是共識，但目前的工具尚未對這個過程提供完好的支持。這我們可以從系統重構時程序員大量的查找替換拷貝粘貼就可以看出來。

2 不能以輕視的態度看待所謂的語法糖，拋開OO的所謂哲學，僅僅把那些所謂的抽象看作語法糖。其實沒有什么抽象的概念，當我們說“繼承”，其實只不過是在說一段代碼，而且一般來說是在設計時運行的代碼罷了。如果“繼承”代碼在運行時運行，那就變成了一種具有病毒特征的高效的動態語言。

3 設計時與運行時的關系，尚未得到徹底的分析，我想一旦深入理解了這種關系，所謂靜態語言與動態語言的鴻溝就不復存在，我們可以在效率與靈活性之間從容取舍。

4 再來看所謂的現代開發工具對效率的要求不高的說法，也是有前提的。我們只不過感受不到效率的限制而已。事實上，對效率的要求，已經使我們被迫放棄一些看起來優雅的設計。舉一個極端的例子，在位圖編程中，我們無法把單獨的像素看作一個一個的對象，即使這可以讓程序看起來簡單。如何讓優雅與高效并存，也是一個不小的課題。雖然完全并存是不可能的，但我以為現有的語言在這方面的提升空間還相當大。

5 程序員之間的交流，文檔是靠不住的，唯一靠得住的就是代碼，包括靜態的，尤其是動態運行的。未來的開發工具應該正視這個問題，為程序員之間的交流提供優秀的方案，這看起來是提高團隊工作效率的最有效的方法了。舉一個另類的例子，可不可以在一段代碼上附加一個錄音注釋呢？

6 AOP所揭示的是一個方向，但目前做得遠遠不夠。設想一下我們在設計程序的過程中頭腦中浮現出來的各種隱喻，指導我們敲下代碼的頭腦中的模型。當我們對接班的程序員介紹的時候，是先給他講這些隱喻，模型更有效率呢，還是直接看一段糅合了N個思路的代碼更有效率？其實，在瀏覽代碼時，我們也只能通過恢復設計者的數個思路來理解，而不是直接通過代碼來理解。

7 讓用戶編程，似乎是個瘋狂的想法，但在某些時候，編程比操作按鈕來得更加友好。以此為思路，任何軟件都是一個自開發的工具。

8 大教堂與市集的愿景是好的，但缺少一條最根本的東西，商業利益驅動，不同于那些軟件共產主義分子，我認為一個靈活的市場機制，是發揮每個人效能的最佳環境。我們未來應不必在opensource和closesource之間進行取舍，這也是開發工具所應支持的。

9 在一個復雜的繼承關系中，基礎類的修改往往意味著新產生無數的Bug。其實，如果在運行時引入版本概念，我們往往可以對系統進行細微的，不那么符合OO的小修改，但是卻能很好的工作，也能很好的理解。至于不符合審美的問題，如果是工程，那么就此結束，如果要復用，那么再繼續調整。OK，這里談到我的一個核心概念，把繼承當作版本來處理，版本管理所能處理的要更加廣泛靈活，而繼承只不過是一個特例的應用而已。

目前我們主要基于witrix研發行業軟件，本身并無意推廣witrix平臺。現在witrix所承載的核心應用對它的靈活性和性能都有著很高的要求。
1. witrix技術的創新之處在于提供了程序結構的新的抽象和融合方式，它所帶來的價值主要是程序的持續改進能力。在公司里我們是嚴禁拷貝粘貼的。可以重用的業務邏輯總可以抽象為某種技術實體。
2. domain specific的語法我們認為非常重要。很多人傾向于使用非常強大的語言，這種語言允許構造所有復雜的局部結構，但是在我們看來，再復雜的通用語言也無法涵蓋各異的業務邏輯，而語言本身提供的抽象能力至關重要。同時我們還非常關注于抽象出的技術結構的穩定性。假如做一件事情有n種語義等價的方式，而且沒有一種強制手段可以進行形式校驗，則任何一種抽象得到的結構都是不穩定的，因為我們總是會受到各種誘惑偏離一種固定的形式，最終造成形式的解體。
3. 我們在編譯期作了很多工作，這是解決系統結構問題的一種重要手段。在沒有得到全部信息的情況下（沒有運行時的數據信息），即使沒有類型概念，我們仍然可以在結構方面作很多文章。
4. 現在很多情況下其實是沒有很好的抽象方式。比如說，如果把位圖的每個像素都看作一個具有自我活動能力的對象，我們遇到的問題首先是巨大的管理成本，這遠不如把它看作只接受外部控制的數據信息更直觀，更簡單。一些所謂優雅的設計只是在最模糊的印象上似乎很時尚， 但是真正細致到細節的時候，它遠不能提供我們所需要的結構控制能力。
5. 代碼是交流的重要工具。witrix設計的一個重要目標就是代碼的可描述性，編碼的過程就是描述系統結構的過程。我們正在盡力縮小需求描述與代碼結構之間的概念差距。但是很多時候代碼是信息不完全的，有些信息我們寫在了代碼之外的文檔中，特別是一個設計的原因是什么，為什么采用當前的處理方式。
6. AOP的原始形式存在一些隱蔽的問題，直接應用AOP效果是有限的。在witrix中我們是對AOP的概念體系進行了補充，才定義出足夠強大的結構組合方式。
7. 對程序員來說代碼更加便捷，但是工具仍然是有效的，它可以限制程序的可能性，大大提高我們構造某種業務流程的可靠性。
8. 商業是一方面，人的精神和傳統是另一方面。
9. witrix目前就在運行時管理著大量的代碼版本，繼承只是一種初級的結構融合手段。

對設計有興趣的朋友可以通過 canonical.cqh@gmail.com聯系我