reply On literate programming

On Literate Programming | Surely I Am Joking

对于文学化编程,俺使用的是 Leo : http://wiki.woodpecker.org.cn/moin/LeoEnvironment

你提及的:

• 丢失了全景思考
• 程序不仅仅是文本
• 人的语言/认知 至上
• 痛苦的导航

几个观点中,俺非常同意的是:

• 目前并没有一个,可以真正统一人的思想以及程序代码形式的编辑方式/环境

但是,目前为止,在代码的语法结构维度之上,可以给予我们一个可以自在记录原始思路的编辑方式,应该只有 LP 了; 从俺使用 Leo 进行各种编辑/编程 的体验而言

• LP 其实是关注包含时间维度的代码的变迁过程,而不是简单的精细化切分
• 其实,到最后看起来是碎片的代码片段,以及关系,并不是从一开始就形成的
• 而是在开发的过程中,逐步抽象/提取而成的
• 也就是説,在 LP 的编辑思想中,人的整体思路是最重要的对象,是必须随时加以记录的

程序当然不仅仅是文本

• 但是,程序只能以文本形式来管理/编辑/传播吼,,,
• 当然的,因为 LP 不关心 程序文本的运行时结构,所以,无法自动跳转到相关定义...
• 不过,俺感受到的是:
• 记不住的就是不重要的
• 不知道的就是不必要的
• 如附件截屏:
• Leo 通过可视化的树形结点来记录了我对程序的整体思考
• 而右方的编辑区,永远只是当前结点的内容

也就是説,通过 Leo 进行文学化编程的整体过程是一系列相同的重构过程串起来的:

1. 定个文件的框架
2. 定个大致的(子)功能流程,每个先以可运行的伪代码记录下来
3. 进入对应的结点完成功能
4. 每当超过一定的行数 hold 不住了,说明应该进行重构,将重复部分抽象出去了 回到第1或是第2步...

所以,如果是 Leo 这种的文学化编程环境

• 并不太需要 IDE 类似的全程自动解析,追踪,导航,以帮助我们快速定位代码
• 因为,每次进行修訂的代码片段都足够小,关注的因素也足够少
• 而每个足够小的片段,都是从足够大的上层逻辑节点演化来的
• 即,有关整体程序的概念,结构,思路,永远在 outline 的节点树中有体验

不过,你点出的工程性问题的确存在

• 同 coffeescript , Leo 进行编程调试时,一样麻烦在
• 如果调试运行时,引发错误的代码,超出当前编程的片段范围时
• 错误信息反馈的行数,在 Leo 中找不到精确的对应
• 所以,只能 到输出的正常文本程序中搜索,明确了代码所在代码段后,才能回到 Leo 人工定位到对应的

期待你的大一统式编程/测试/运行环境!

Changelog¶

• 140109 pub. as zoomquiet.io's blog
• 120918 邮件 as:

  发件人:     Zoom.Quiet <zoom.quiet@gmail.com>
  发送至:     shredderyin@gmail.com
  日期:  2012年9月18日 下午5:22
  主题:  [via On Literate Programming] 我的体验
  
  很有感觉,但是没有找到评注入口,只好直接邮件了;
  

askdama@googlegroups.com