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
    日期:  2012918 下午5:22
    主题:  [via On Literate Programming] 我的体验
    
    很有感觉,但是没有找到评注入口,只好直接邮件了;
    

Comments

comments powered by Disqus

© Copyright 2014 by Zoom.Quiet
Content licensed under the Creative Commons attribution-noncommercial-sharealike License.
Contact me via , mail ,github or bitbucket . Tip me via gittip . (feed)