經過半年的實踐，期間也斷斷續續的在折騰自己所寫的一個文式程式設計工具。現在可以正式但不嚴肅的談談對文式程式設計的一些體會了。
寫程式不難，關鍵是寫出有用的程式。
寫出有用的程式也不難，關鍵是寫出可讓別人繼續維護下去的程式。
文件是重要的，沒有文件，單憑程式碼中那些經常很蹩腳的變數名與函式名，往往很難理解一段程式碼的功能及用途。$y=ax^2$ 是拋物線吧？那 $E=mc^2$ 是什麼？程式設計雖然也像數學那樣依賴於符號，但它更像是物理學。
程式語言所提供的註釋機制可以解釋程式碼，但是它不能替代程式文件。如果將一個程式視為一部電影，那麼程式碼的註釋像是電影裡的旁白，而程式的文件則是這部電影的劇本。
閱讀沒有文件的程式原始碼，閱讀者弄懂這些原始碼的過程，本質上只是為這些原始碼重新撰寫了一份文件。去為一份並非自己編寫的程式原始碼重建文件，困難係數通常遠大於程式原始碼的作者本人來寫。
寫文件，所耗費的精力與時間往往要大於寫編寫程式原始碼的時間。這是很多程式缺乏文件——抑或有文件，但是文件往往落後於原始碼幾個世紀的原因之一。另外一個原因，寫程式的人多為理工科出身，文字表達能力通常比較著急。雖然 Knuth 於上個世紀 70 年代就在倡導文學程式設計的理念，但是迄今為止還沒聽說過哪個寫程式的人用文學程式設計寫出了一部發人深省的作品。不過，可能更主要的原因是，老闆們不會為此多給錢，甚至會因為你程式碼寫的慢而開掉你。
這一現實讓我不好意思在這裡談什麼文學程式設計，還是弱化一下，稱之為『文式程式設計』更好一些。
按照柯里-霍華德同構定理，寫程式的過程與證明一個數學命題的過程是等價的。也就是說，我們寫程式，本質上就是一連串的推理過程，當程式能夠執行起來，並且能夠正確的解決我們要解決的問題之時，這意味著我們已經完成了一個數學命題的證明。如果將這個推理的過程用文件記述下來，並且將程式的原始碼也嵌入這個推理的過程之中，作為每個推理階段的所得結果，這樣就實現了程式文件與原始碼的融合。這樣的結果必定不是文學作品，而是一篇論文。
每個人寫程式的過程，其實是有程式文件的，只不過他們沒有把它寫出來。他們像拍電影一樣，基於劇本，一個鏡頭一個鏡頭的將電影拍出來，然後燒掉了劇本。
要用好文式程式設計，必須要按照一個問題的推理順序將文件與程式碼一併寫出來。