我理解中的 Live Coding

[tiye]

探索 GTK 的时候对 Live Coding 有一些想法, 我结合我看到过的描述下吧
先梳理一下我之前微博上看到过的消息:

简单的理念来自动态语言的解释执行代码, 最早 Lisp, 其后的 Bash, Perl, Haskell 等
现在我们周围的很多语言, 特别壮观的比如浏览器环境都是非常方便和环境交互
但通常 REPL 的设计都是单行, Bash, Python, Coffee 都用特殊语法才能输入多行
而 ELisp 和 Firefox 的 Scratch Pad则在编辑器中集成代码执行, 就像
http://jeditoolkit.com/2012/11/12/interactivate.html
还有@Emerge 推荐过的视频, 用图形显示代码的运行, 但其创意比这里说的要多
www.youtube.com/watch?v=R3MNcA2dpts

在另外 gdb, pry, Chrome 那样的调试工具应该是更好的 Live Coding 的工具
可以在代码运行中某个环境跑测试的代码, 查看代码运行的状态并做修复
个人使用调试工具较少, 导致我倾向于代码本身具备调试功能, 而不是扩展工具
心里还是依赖着有强大的工具发布.. 因为我以为目标就是看清代码执行中的结构
即便大脑去模拟代码执行, 也仅仅是逐个验证数据状态, 借代码本身模拟显然更好

上边的例子主要是代码部分执行, 而不是打大段代码的编写过程
Live Coding 发生的, 通常是在代码编写过程中即时地查看代码的效果
比如 Wiki 上链接的一个用代码编曲的视频, 随时查看编写的效果
http://en.wikipedia.org/wiki/Live_coding
这更合人们创造手工的过程, 一边做一边看一边改, 直到成为一个完整的物件
大概不符合机器生产的流水线模型, 却是通常我们探索和发明的方式

Live Coding 比较清晰的一个例子是 JS 监视文本框的输入, 实时执行代码
这样实现起来比较轻松, 并且在网页上直接展示的例子是比较多的, 比如
http://nodeca.github.com/js-yaml/
而 C 一类编译型, 我见过只有 Circa 能在 C++ 游戏运行过程修改代码
http://circa-lang.org/about/introduction.html
相似还有 JS 代码编辑过程就在边上实时绘制图形的
http://flowingdata.com/2012/03/19/live-coding-implemented/
http://mrdoob.com/projects/htmleditor/
这样更多的例子其实都能用 Bret Victor 大神的想法来串联
http://nornagon.github.com/scrubby/

Bret 的视频当时震撼了我, 他手中的代码能看到形态, 能看到过程
而面对抽象的代码执行过程, 我非常期待能如此看到代码生动地生长起来
http://vimeo.com/36579366
http://worrydream.com/LearnableProgramming/
Light Table 就是受此指引设计的编辑器, 代码将会实时地执行
并结合 IDE 所需的功能, 展示出更多关于代码本身以及运行的信息
http://www.chris-granger.com/2012/05/21/the-future-is-specific/
也赖现代的动态编程语言许多灵活的特性, Chris Granger 给了一个同样动人的例子
http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/

对 Live Coding 那样的调试方式, 我在折腾网页时时时用到
前端调试 CSS 和 jQuery 常要按 F5 刷新, 有了 Node 的协助这都是做动完成的
同样一些 Node 小程序, 用 node-dev 也自动重载, 那都是机械的操作
我观念中的编程就是不断涂抹代码直到完成, 完全消掉编译和重启的工作量
代码不是一蹴而就的, 大脑总是要从各种异常中找到问题的关键所在
当然, 要找到问题所在, 看清代码运行的过程是必不可水

当我被 GTK 那些 C 文档挫败的时候, 我想到去查看代码本身
就像最初学 JS 那样, 去打印对象所含的属性和方法, 作为 API 文档
在我不惯用的 IDE 中, 类似功能是存在的, 只不过那不是代码执行时所展示的
极端的像王垠说的同时解析其 AST 提供补全, 但我没有是用的经验
语法补全和代码真实的执行环境有区别, 我目前倾向于执行

另一个我遇到的问题是找到 API, 但参数类型和功能并不清晰
那么自然我想到要打印 API 同时展示相关的文档, 引导用户使用
Python Clojure 在定义函数时使用 doc string, 在这方面有例子
http://www.python.org/dev/peps/pep-0257/#what-is-a-docstring
http://clojuredocs.org/clojure_core/clojure.repl/doc

其实文档本身也有问题, 动态语言比如 jQuery, 在教学阶段就有各种例子
通过网页上真实可见的例子, 开发者能很快了然插件所要执行的功能
大多语言的文档只是死板写出了输入输出类型, 我认为太过于抽象
我的观念里学习是先模仿, 然后思考. 如果仅靠思考, 那就像机器证明看那么刻板了
人类的大脑擅长于情节, 擅长于想象, 因而我有点反感那种刻板的学习方式

还有一个问题像 Clojure 或者 GTK 程序的重启, 时间上不允许那样调试
http://martinsprogrammingblog.blogspot.com/2012/02/why-is-clojure-so-slow.html
文章开头 REPL 似乎是对此一个不错的解决方案, 因为能减少代码的重载
REPL 不足在无法四处跳转修改代码. 如果要实现, 恐怕要标记源码和内存数据
之后只对涉及修改的部分进行重载, 那样就不再是一遍遍消耗资源了
编写软件是艰难的, 所以我想多花费功夫去改进不会是偏离重点
也不知道现在有什么项目解决了这样的问题呢?

结尾说下 Lisp 吧, 从上次 Chicken 执行速度不如 Node 和 Luajit 我就失落了
http://www.douban.com/group/topic/34481125/
虽说 Scheme 最快要 Gambit 和 Stalin, 可 Chicken 也是编译到 C 的那种速度
其实 JS 和 Lua 说白了是山寨的 Lisp, 我用惯了并不觉得 Lisp 多么出彩
或者说当置身网络想一些东西, Lisp 哪有多少先进? 主要是失望..
也许 FP 价值在于让人看得更远, 然而现代编程语言站在 FP 的肩上也能看到

我不精通 JS, 也不熟练 FP, 写的必然有错误, 上面是我真实的想法

[Liutos]

期待越大失望越大～

[ghost]

Livecodelab http://www.sketchpatch.net/labs/livecodelabIntro.html 这个漏了么，很不错
(fluxus) http://www.pawfal.org/fluxus/ 还有这个

[tiye]

@Emerge 你这第二个神了, 自动编程的.. 第一个沒弄懂. 我想例子总是能有很多

@Liutos 不清楚你指的是什么. 不过说起来我一直在对各种编程环境失望着

[Liutos]

就是指你的那句

我用惯了并不觉得 Lisp 多么出彩，或者说当置身网络想一些东西, Lisp 哪有多少先进? 主要是失望
啊～

[ghost]

了解Lisp和这些函数式（指广义的：过程描述）完全没前途了吧，正是因为都没进步，所以这些语言总是将各种无聊的小细节改进和实现问题当作多么大不了优点和进步。比如他们吹得最凶的：表达式、元编程、数据模版、闭包、OOP上，一个flow1秒它们全部了。类型系统和模式匹配？两个悲哀的无法融入的补丁特性，在函数式里永远那么丑陋。未来的语言首先要参考的是Prolog。