I’ve been watching Chris Granger’s Light Table project for a few months now (apparently, since April) and the more I think about it, the more I like it. According to their Kickstarter, the rough estimate for release is May 2013. When it comes out, it’s supposed to support Clojure (a Lisp dialect that initially ran on the JVM but has a variety of ports), JavaScript, and Python - all dynamic languages with powerful tools for instantly providing feedback. The link in the title of this post will get you to the version 0.1 demo, which currently only supports Clojure.
Even though I like Emacs and have no trouble using a command line tool like Leiningen (aka lein), I see a lot of things to like about Light Table. I like the fact that lein is now built-in, and you can get started with a project right away. The Instarepl is fun to play around with, and it’s something that would be difficult for a purely text based editing environment. With the addition of the Table in the latest version is, things have gotten a lot more interesting. What they’ve done is emphasize the structure of functional programming through the structure of the IDE - you work with a bunch of discrete, self-contained units and gradually combine them into a unified organism (to take some inspiration from the preface to Structure and Interpretation of Computer Programs).
Working in a buffer of code, if you find that you need to re-arrange some units, it’s a lot of work. Light Table presents these units as being completely distinct from each other, making it easy to navigate between them and move them around. I assume the final product will make it easy to travel between the different views of your code - I’d love to shuttle a bit of code between the Table for editing and the Instarepl for testing, for example, but at the moment that doesn’t seem to be possible. The constant documentation lookup presented in the Kickstarter pitch+video is nice, as well, and I think it would prove to be more useful than having a hotkey to go looking for a bit of documentation.
The moral of the story, though, is that these are the kind of things you put together when you look at the logical structure of code. Extending Light Table in JavaScript, as demoed by Chris, actually winds up leading to more impressive extensions than most of what you see for Emacs. Emacs has tons of awesome extensions like Org mode; but your power starts and ends with text processing. You can make nice tables in Org mode - I’ll happily concede that you could write a similar benchmarking mode that outputs an Org file. That’s pretty simple in plain text.
What about displaying the contents of a database on the fly? It seems to me that Emacs isn’t so great at displaying constantly changing data like that (ie as you change the code in the associated buffer), but I could be wrong. But until someone completely revamps the rendering engine in Emacs (which could be a long time coming) you just can’t embed a webpage in Emacs. Full stop. No, viewing it in plain text with w3m doesn’t count. No, converting the webpage to a pdf and displaying that doesn’t count (yes, Emacs can do that). I mean honest-to-goodness embedding the webpage, such that you can interact with it and see it true to life, including its JavaScript and other stuff that probably stumps text-based browsers like w3m.
This isn’t just an abstract problem - displaying text with heavy formatting is basically impossible in Emacs. I’ve been looking at using Emacs to write LaTeX for papers, and the workflow is pretty crappy. You write your LaTeX document, you compile it and output a pdf, then you display the pdf in Emacs or in a standard pdf viewing program (on Windows, SumatraPDF is a good choice because it won’t lock the pdf file while you’re viewing it). Compare that to Gliimpse - personally, I’d like a version with instant transitions, but that’s just me. With or without transitions, it’s the same idea. You write your markup, you take a second to see what it looks like, you switch back to the markup to make some changes. Tada!
Contrast that with the current workflow - you write the markup, compile the new version, open the pdf, check out your changes, make some adjustments, recompile, re-open/refresh the pdf… A dual-pane environment for writing Markdown is actually available online, but I’m having a hard time finding anything similar for LaTeX. If Emacs had a rendering engine capable of displaying LaTeX documents accurately, it would provide leverage for a plethora of useful tools, stuff above and beyond the demos Chris put together.
Until then, we have Light Table.