（實現方法和scheme中的鏈表思想幾乎完全相同——不過版本控制本身就是一堆指針，參考 鏈接：git教程 - 廖雪峯的官方網站）
博客提供兩個接口：
寫博客，可以在博客裏放任何內容
不限量評論
評論可以刪除
博客常常可以修改。但是這個功能有副作用：修改之後，歷史版本就消失了——所以最終沒有用到這個特性。接下來是實現：
def 創建一個project：
新建一個具體實現的blog
新建一個寫上項目相關信息的blog #需求的改動按理較少
用實現blog的網址評論項目相關信息的blog，並註明這是用於實現的東西
def 更新實現：
新建一個實現的blog（複製原有代碼，修改）
把項目相關信息blog下的實現地址刪了，加上新的實現地址
def 回退：
把項目相關信息blog下的實現地址刪了，加上要退到的版本的地址
def 提交分支：
做一個實現blog
在項目相關信息blog下追加評論新的地址
def 查看歷史版本：
打開博客列表
def 合併修改：
exit("不好意思，不可以合併修改！")
完工！！
非常簡潔漂亮的實現。但是這個實現也帶來了一些問題：
如果有非常多的改動，那麼代碼被反覆複製，造成了非常多的冗餘
整個工程只有單個文件
如果兩個人開發兩個函數，兩人寫出的新代碼，需要仔細思量纔可以整合
對於單文件問題，其實blog很容易就可以支持多個文件。只需要額外創建多個blog，分別寫各個文件，然後在實現的blog裏寫下“本工程包括文件：xxx，xx，xxxx……”即可（當然，要註明對應blog的地址）。如果新的版本改動了其中一個文件，那麼新的實現blog只需在已有基礎上修改其中一個文件的指向即可。
對於冗餘的問題，可以通過引用來解決。比如刪除前3行代碼，新的文件中只需要寫“在xxx的基礎上刪除前三行”。假如有多個這樣的描述，那麼把它們連在一起就是整合修改（衝突是可以檢查的）——當然這需要一種規範化的語言，來使得可視化變爲可能（藉助php等手段翻譯），否則並無法直觀地看到修改後的真實代碼。————說到這裏，你肯定會說，這不就是git嗎？————固然是極其相似的，但這時並非是由git檢查來確定修改，而是由編寫者來決定哪些地方作了修改，或者要求編寫者總結何處作了修改，或者直接使用新的代碼。這應當會使得代碼更易理解，並且一定程度上可以標記出代碼的局部回滾（假如只有一個文件需要使用之前的版本）
完工了嗎？也許，畢竟即使翻譯需要論壇的支持，我也沒能具體給出某個修改語法。局部回滾也顯得很勉強，似乎還缺少一個目錄結構（不過和unix目錄亦文件的哲學非常相似），而且反覆引用會使得求值緩慢（這個可以在實現的時候使用緩存，blog不可修改，以後的改動不會有副作用——函數式編程）；python的最小單位往往是行，但某些語言的最小單位是類，這時候的修改需要一種新的（可能是遞歸的的）標記方式，或者混用多種標記方式；項目信息的描述也可能改變，也需要使用地址……總之，總之……這些都太像開玩笑了。
（2018-6-5 於地球）