现代刨沙艺术 ~weng cv misc contact blog 博客


Light Table Recap

2015-10-16

λ. 1. 为什么关注Light Table

在学习Swift的时候,尝试了Xcode的Swift Playground。不禁让我联想起多年以前看过的Bret Victor的视频Inventing on your Principle。和朋友吹牛,我说发现这两个东西很像。谁知道一查,发现还真有联系。Chris Lattner(LLVM、Swift的主要负责人)在他的个人主页上提到:

Playgrounds were heavily influenced by Bret Victor’s ideas, by Light Table and by many other interactive systems。

有趣的是Bret Victor本人并不知道,甚至还在Quora上否定了这一点。Light Table官网的文章Light Table and Apple’s Swift也谈过这件事。

λ. 2. Light Table是什么

Light Table一款IDE。Light Table最初由Chris Granger提出。Light Table提出了一些创新的特性,旨在优化使用体验,例如运行结果的实时显示、更好的代码结构、更方便的文档查询等等。具体特性将在下一节讨论。Chris Lattner在Xcode中加入的Swift Playground就源自Light Table的影响。

Light Table代码主要由Clojure组成。源代码托管在github。目前最新版本是0.8.0。

reddit上/r/lighttable最新的帖子是一个月前,次新的是六个月前。HN上新闻也很少。Light Table曾经在kickstarter上筹款,上面最近的动态是去年发布的0.6.0版本更新公告。Google Groups两三天有一篇新帖子。github上的项目还在提交commit,gitter也还有人在讨论。最初的作者Chris Lattner最近三篇博客提到了他的新项目Eve,也提到Light Table会继续维护。感觉上虽然还有人在开发维护,但是用户已经很少了。

我试用了Mac上最新版的Light Table,包括Clojure、Python和HTML相关的编辑、运行的功能,Clojure的live edit mode和Python的单行执行。软件常发生卡顿,或者connection时间过长的情况。

λ. 3. Light Table有什么的特性

摘自官网

λ. WATCHES

Next-gen println to keep track of important values in your code. Just add a watch to an expression and the value will be streamed back to LT in real time. WATCHES LT在代码后方直接显示watch的变量。

λ. INLINE EVALUTION

No more printing to the console in order to view your results. Simply evaluate your code and the results will be displayed inline. INLINE EVALUTION LT可以执行整个文件。LT也可以执行单行代码。

λ. MALLEABLE

Keymaps, behaviors, and Light Table’s Behavior-Object-Tag engine means you can easily shape your IDE to whatever your work requires. 这个指的是IDE本身方便扩展

λ. PLUGIN MANAGER

The plugin manager hooks into the central list of plugins so you don’t have to go hunting all over the internet to find the ones you want. 同上

λ. POWERFUL EDITING

Light Table is a lightweight, clean, and sleek interface with all of the power and functionality you need and expect from your editor. 指的是Editor的功能多。

这五点是官方Features列出的。后三点并没有太多说道,有趣的是前两点。Swift的Playground借鉴了第一点:在行右方显示输出、自动执行文件。

这里写的输出,并不是单指println这类函数的输出。对于赋值语句,LT显示变量的值;对于函数调用,LT在函数代码所在的行右边,显示最后一次调用该函数时的参数值,以及函数代码中赋值语句的变量的值。

LT对不同语言的支持由对应的插件提供。对于Clojure,LT提供live mode和instaREPL。对于Python,LT的单行执行可能由执行于后台的IPython配合完成。对于JavaScript,LT的单行执行由JS虚拟机配合完成。

λ. 4. 关于Light Table的architecture

HN上有一篇《Chris Granger on the LightTable architecture》的帖子 HN链接 原文链接

作者提到:I think it’s time for an honest look at where things are. Even with a principled approach, I think I managed to build a system that only I can really get around in. BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I’ve recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins.

大意是:BOT是个很好的架构,但是太晦涩了。BOT全称是Bahaviors, Objects and Tags。其实我之所以之前用了“可能”,就是LT的源代码我看的似懂非懂,有些机制不能确定。已经在gitter上提问了,暂时没有得到回复。(BOT细节可以参考作者的文章 The IDE as a value。我没有看。)

Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges. So while you can build a pretty incredible amount of functionality in less than a hundred lines in LT, doing so requires you to pretty much understand the whole system. This is a failing on my part. I optimized for keeping the codebase small enough that one person could work on it and along the way I ended up making decisions that ultimately made it more difficult for others to contribute.

这段具体说了Mixin的缺点,简单来说就是dynamic的结构太复杂了。

The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself… When I first started I was more or less the first person to use node-webkit, CodeMirror didn’t even have a separable text model (we actually contracted Marijn to add it), and there was quite literally no tooling for ClojureScript. A whole lot has changed, and I would certainly do things differently if I were starting from scratch today. For one, I probably wouldn’t have chosen to do it in CLJS. It’s just too much of a moving target and architecture ends up being far more important than the specific language used. Using Clojure(Script) also reduced the pool of possible contributors. Starting over, I’d build the UI in an immediate mode fashion, though I probably wouldn’t choose to use React directly. I’d scrap BOT for something that is a little less powerful, but far easier to reason about (if people are interesting pursuing such a thing, happy to share my thoughts).

这段话说工业界的趋势变了。

λ. 5. Chris Granger的其他文章

作者在个人网站的很多篇文章里,重新思考LT及他对编程、编程工具的看法。我看了他网站和LT官网里所有的文章,觉得以下几篇值得阅读。


Light Table Recap