Light Table Blog

Warning: fanboy gushing ahead. Read at your own risk.

Interactive web-based documents are not new, nor are the ideas that Bret Victor is exploring, but a synthesis as sophisticated and holistic as Bret's is.

One core idea embedded in all of Bret's work is that learning happens best when students are able to explore multiple representations of a idea or aspects of an environment simultaneously. The more quickly one representation changes in reaction to the other, the stronger the learning feedback loop, and the more quickly the student builds an accurate mental model of how the thing they're interacting with works.

So, WRT your point, it's not about the fact that the documents are interactive, but that they're "reactive." The interactive bits are all related to each other, and when one part changes all the other parts change with it, in real-time.

There's something in this immediacy that even the slightest delay destroys.

That's not a new idea; anyone who has read Mindstorms (1980) or grew up on LOGO has had at least an inkling of it. Lots of research ink as been spilled over this, and many "pedagogical" programming environments (Scratch, etc.) flirt with it. Even Bret would say that, I bet.

But, well, he's taken it to a whole 'nother level. He's actively exploring this idea on multiple fronts, from reactive documents to reactive programming environments, and shitting gold all around town.

Every time he publishes something it takes months for people to react,…

Warning: recent history lesson ahead.

> One core idea embedded in all of Bret's work is that learning happens best when students are able to explore multiple representations of a idea or aspects of an environment simultaneously. The more quickly one representation changes in reaction to the other, the stronger the learning feedback loop, and the more quickly the student builds an accurate mental model of how the thing they're interacting with works.

Bret Victor's work brings a lot of visibility to this field, but he was hardly the first one; e.g. [1]. And more to the point, I wasn't the first one either; I believe Christopher Hancock [2] was, but even that is controversial if we begin to talk about visual languages all the way from Sutherland's SketchPad, and Jonathan's work on subtext [6] was a big inspiration to my own. And even I was inspired by some piece of software called SlideShow [4].

> So, WRT your point, it's not about the fact that the documents are interactive, but that they're "reactive." The interactive bits are all related to each other, and when one part changes all the other parts change with it, in real-time. There's something in this immediacy that even the slightest delay destroys.

50 milliseconds is the max, ideally you want < 20 ms (see [1], keep in mind 15 ms is your standard frame delay).

> But, well, he's taken it to a whole 'nother level. He's actively exploring this idea on multiple fronts, from reactive documents to reactive programming…

On the other hand, the only usable Intellisense engines or debugger integrations I tried have been built for Emacs and not Vim. This is mostly because, by design, offloading tasks to other processes without blocking the gui-thread is easier to do in Emacs. Also Vim really needs good integration with other languages such as Python, because Vimscript is simply awful.

There are problems with Emacs. First, Elisp is kind of an outdated and dirty Lisp dialect. It's kind of neat for extending Emacs, but it's also a poor Lisp dialect by modern standards. I would love an alternative to Emacs built on top of Scheme, with its awesome continuations support, or on top of Clojure.

The other problem I'm seeing is that Emacs, as awesome as it may be, is also outdated in what it can do. Smalltalk set a high bar long ago in what IDEs can do and Smalltalk IDEs still haven't been surpassed in terms of experimental development that people tend to do in REPLs nowadays. Having something like a Smalltalk IDE, that uses realtime feedback and visuals to aid in learning, discovery or debugging, with the same philosophy of Emacs (e.g. open-source, totally customizable, turtles all the way down, transcending languages or operating-systems, etc...) would be priceless.

This is why I have high hopes for Light Table [1], hopefully it will bear fruits as planned by its author.

[1] http://lighttable.com

I personally think path 1 is absolutely where editors should be going. Upvote from me.

NeoVim is a step in the right direction, but not far enough. The future is a more Light Table like environment (http://www.lighttable.com/). But Light Table (as visionary as I think its UI is) is written (and extended, AFAIK) in ClojureScript, a LISP-like language that nobody knows.

It it was written and could be extended in JavaScript instead, and configured to the extent that I could write VIM-like modal editor support for it, I might finally be able to give up VIM after 20 years for something better.

brackets is open source http://brackets.io/

about this, I use brackets, a lot of it does look like brackets maybe with some ideas taken from light table http://www.lighttable.com/

There's a thread on discuss.atom.io about what distinguishes the two http://discuss.atom.io/t/what-distinguishes-atom-io-from-brackets-io/511/9
I guess I don't feel atom does enough different from brackets that I can justify switching editor at this point, but if anyone has more to add than was found there I'm interested to hear.

I believe LightTable [0] ran with some of the concepts in the video, and I remember one of Chris Granger's videos having an almost identical bit about mapping time over space in a ball/block jumping game and very similar themes. Either way, it's definitely worth checking out. Sorry if I get any of the details wrong, I'm a bit out of step with Clojure.

[0] An IDE that supports Clojure and Javascript right now, maybe Python soon? Bit behind on the news: http://www.lighttable.com/