本文探讨了文学编程的概念及其在Python编程中的应用。介绍了Donald Knuth提出的这一理念，并通过leo编辑器的实际使用体验进行了阐述。讨论了如何将文学编程的思想融入日常编程实践，以及这种方式对于提高代码可读性和维护性的潜在价值。
【转自：http://markmail.org上几位大人的邮件讨论。原汁原味的，大家自个儿看吧】
=================
[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():
<<init>>
<<process>>
也就是说从粗到细。通过<<name>>的形式来包含代码块，不需要让人一下子就看到细节。这样处理的话，更方便文档的写作。因此采用这种方法，可以方便地将文档与代码穿叉起来。
文学编程本身就是更看重文档，如果对文档不感兴趣，不需要使用文学编程的形式。而且他完全可以修改生成后的东西。贡献的方式也有很多，也不一定需要直接修改原始的东西，可以通过补丁之类的来实现。而且先想到可以自已用，而且能够真正实用，再考虑给别人用为好。别人如果不接受这种思想，光有好的想法也是没有用的。
因此首先是让自已适应。不过的确可以考虑反向代码合并的处理，只不过要加些特殊的标记。其实在leo处理分布文件时也是有许多特殊的注释，你可以不用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。
=================
=================
[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():
<<init>>
<<process>>
也就是说从粗到细。通过<<name>>的形式来包含代码块，不需要让人一下子就看到细节。这样处理的话，更方便文档的写作。因此采用这种方法，可以方便地将文档与代码穿叉起来。
文学编程本身就是更看重文档，如果对文档不感兴趣，不需要使用文学编程的形式。而且他完全可以修改生成后的东西。贡献的方式也有很多，也不一定需要直接修改原始的东西，可以通过补丁之类的来实现。而且先想到可以自已用，而且能够真正实用，再考虑给别人用为好。别人如果不接受这种思想，光有好的想法也是没有用的。
因此首先是让自已适应。不过的确可以考虑反向代码合并的处理，只不过要加些特殊的标记。其实在leo处理分布文件时也是有许多特殊的注释，你可以不用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。
=================
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
