***************==
[b]limodou:[/b]
文學程式設計不是乙個新東西，是由donald
knuth提出來的。不過我接觸經時間很短，但在cpug第九次會課上聽了zoom.quiet關於leo的講解開始有所體會。再看一看我寫的django
step by
step，現在我想，如果在寫教程時，其中的**就是最終的執行**，那麼等我的教程寫完了，程式不也編完了嘛。當然這其中操作起來還有難度。不過我不想使用
leo 來進行文學程式設計。大家有什麼想法嗎？可以考慮開發乙個從rst中提取**的工具？還是有更方便更好的想法。
***************==
[b]馬踏飛燕:[/b]
文學程式設計我還沒搞清楚它的精要，不過倒是leo的研究有了點進展，哈哈！
因為leo是用tree的結構組織的，所以對node的操作就很方便了。
不管是寫計畫，還是程式、文件，大都可以先寫在一起，接下來再分離到各個節點。
可以復用的還可以單獨拎出來放到一起，還可以寫一寫指令碼來管理節點裡面的內容或者檔案系統的內容。
不過leo我還是略知皮毛，還需要zoom多分享經驗哪！
***************==
[b]zoom.quiet:[/b]
手冊！例項！練習！截圖！
乙個都不能少哪！
否則，大家僅僅從字面的"文學化程式設計"來理解，一定是偏離的…………
leo 的"文學化"是�借，文學的組織思�來比喻，全新的程式設計行為是也……
***************==
分散的**，這也只在python才有較大的意義，在不具備互動式的環境下，頂多也只有講解的意義。而且從現在來講，文件跟**的這種整合只具有示範的意義。因為目前沒有多少程式支援這樣做。因此，我說雙向自動化就具有了突破的意義。
另外，分離了**再整合回去，可以讓很多人參與，畢竟，沒有多少人對寫文件感興趣。更多的是為了學習。學習的過程就可以貢獻**。文件支援下的**的演化最終還可以支援文件。
***************==
不會只對python感興趣。一般寫**可能是這樣的：
def main():
<>
<>
也就是說從粗到細。通過<>的形式來包含**塊，不需要讓人一下子就看到細節。這樣處理的話，更方便文件的寫作。因此採用這種方法，可以方便地將文件與**穿叉起來。
文學程式設計本身就是更看重文件，如果對文件不感興趣，不需要使用文學程式設計的形式。而且他完全可以修改生成後的東西。貢獻的方式也有很多，也不一定需要直接修改原始的東西，可以通過補丁之類的來實現。而且先想到可以自已用，而且能夠真正實用，再考慮給別人用為好。別人如果不接受這種思想，光有好的想法也是沒有用的。
因此首先是讓自已適應。不過的確可以考慮反向**合併的處理，只不過要加些特殊的標記。其實在leo處理分布檔案時也是有許多特殊的注釋，你可以不用leo修改這些檔案，但這些東西絕對不能破壞，如果破壞掉了，那只有重新設定了。
***************==
但使用leo多了，函式會習慣寫比較長的，這是leo的優點，在其它編輯器上不能看也沒有辦法。就像其它的預處理工具那樣。離了預處理工具總是不方便。
象我上面提出的用folding來代替leo的方案，同樣，有特別的標記，離了folding，用別的編輯器看**會不舒服。
所以，我提出把leo的思想用到平常的python程式設計中，而不直接使用leo。把一段有意義的**盡量做成函式。
但還是leo比較漂亮，因此，儘管leo有一些不方便的地方，但如果用慣了。還是離不了。leo來瀏覽**，很容易讀懂**，**也很漂亮。
這樣說，總是很抽象，只有用過才能體會到leo的好處。才會感覺到，原來，寫**能夠象寫書那樣漂亮，好懂。正因為leo的好處，才有人寧願被leo鎖定，增加乙個程式設計步驟，也不放棄leo。而，也只有用過leo，體會到文學程式設計的好處，才能談離開leo，否則根本不會理解什麼是文學程式設計。
***************==
看來有必要將文學程式設計的思想論述文章翻譯出來，
之前俺講的一些定義可能造成了誤解，
文學程式設計從字面上看是把程式以文章的正式來看待而非嚴格的類，函式等等；
具體的源起我也沒有研究，
只是在一定規模的使用leo 後感覺到文學化的方便，
其實沒有limodou 擔心的事兒，
佷早以前就有類似 treeedit treenote 之類的樹結構資訊組織編輯環境，
而且也有clone 之類的操作，
leo 不過是作的更加精簡而已，
其實不論你使用什麼編輯環境，人們都不由自主的使用文學化的程式設計，
將軟體行為下意識的組織為不同類的動作，不同的動作中又抽象出共同的功能…………
只是在普通編輯環境中只能以有邏輯關係或是命名規則的形式來標識這些"章，節化的程式"
leo 不過是顯式的加強了這樣的書寫，
你可以自由的按照你的諒解將一堆類，函式，片段，說明，等等任何東西組織成乙個節點，來快速你的程式的快捷理解和增長…………
***************==
用leo就是和一般的程式設計不同，很多原來用函式的地方會漸漸的不用函式。當然，也只能用leo來看。leo可以看作**的前處理。既然針對這個前處理寫**，那麼就離不開它了。
當然，多處重複使用的地方還用函式。如果用root方式，多處使用也不同函式。
使用leo會和函式比較矛盾：既然都定義函式了，怎麼還要再做節點？因此，我嘗試不用leo了。用emasc加folding。但這個解決方案更難學，當然，也有他的好處。
使用leo的好處就是簡單、友好。用了leo，感覺非常人性化，符合人的思路，想什麼，寫什麼，較少考慮計算機的流程和實現。但，缺點是和其它工具的結合不是很好。因此，可以考慮把leo的思想融合到程式設計中去，而不使用leo。
另外，考慮把haskell的思想融合到python程式設計中去，而不用heskell。
***************==
關於程式設計的一些思考
1 其實高階語言和面向過程的語言最求的目標都是一致的，高可復用性，另外，封裝性。我發現自己在寫c語言的時候，總是不自覺地就引入了高階語言的一些封裝性的思想 如以下 段1所示 而我的同學卻總是按著最原始的方式對函式進行命名。學過編譯原理的同學就會知道，最原始的c 編譯器其實就是將c 轉化成c語言，然後...
關於程式設計的一些思考
1 其實高階語言和面向過程的語言最求的目標都是一致的，高可復用性，另外，封裝性。我發現自己在寫c語言的時候，總是不自覺地就引入了高階語言的一些封裝性的思想 如以下 段1所示 而我的同學卻總是按著最原始的方式對函式進行命名。學過編譯原理的同學就會知道，最原始的c 編譯器其實就是將c 轉化成c語言，然後...
關於一些C 程式設計的領悟
學校剛剛開了程式設計課，因為我是學軟體開發的，當然就對這個東西很感興趣。由於本人是大一的新生，水平也有限，對c也是不很熟悉，為了達到自己的要求，就在這裡對我所遇到的問題和如何解決的和大家一起分享。希望和我同個級別的也能從中學到些東西。下面是我在實際操作中遇到的問題 說的是如何利用c求解e的近似值 e...