λ. 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。
λ. 2. Light Table是什么
Light Table一款IDE。Light Table最初由Chris Granger提出。Light Table提出了一些创新的特性，旨在优化使用体验，例如运行结果的实时显示、更好的代码结构、更方便的文档查询等等。具体特性将在下一节讨论。Chris Lattner在Xcode中加入的Swift Playground就源自Light Table的影响。
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有什么的特性
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. 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. LT可以执行整个文件。LT也可以执行单行代码。
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的功能多。
λ. 4. 关于Light Table的architecture
作者提到：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.
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的其他文章