Return back to the blog

Light Table: Concept vs Reality

Posted by Prashant Deva on April 22, 2012

I recently came across this ‘concept demo’ of Light Table, which is being passed off as a ground breaking IDE, and has even managed to collect a <a href=””>fair chunk of change on KickStarter</a>.

Being the geek that I am, it piqued my interest too and I took a good look at it. After analyzing the demo, even though the video looks cool, I dont see most of the functionality as groundbreaking and large parts of the demo seem highly contrived. Here are my thoughts and critique on what the Light Table concept demo.

Since I am a Java guy and the IDE concepts are defined as being language agnostic and that support for additional languages can be added later, I will compare the examples using Java code and Eclipse as the IDE.

Let’s look at Light Table, feature by feature.

Docs everywhere


Here the author demos putting cursor on top of method calls and showing documentation on the side. He tries to pass this off as something revolutionary.

Maybe he should just open eclipse and its javadoc view, which does exactly the same thing.

Also unlike what is shown in the light table demo, where the documentation panel eats up half your screen, the javadoc view can be easily docked to any size and resized to preference.

Also the author says ‘docs everywhere’, but the demo shows that there is a special ‘doc’ tab you have to click on to be able to see the documentation (since it eats up half the screen). That means the ‘doc’ is in fact not everywhere and you have to switch to a special ‘documentation mode’ to see it.

Contrast that to eclipse’s javadoc view, which can stay open continuously whenever you want and can be docked and resized wherever you want.

Finding functions


I am assuming java here, so i will refer to classes instead of functions for my examples. Even though java does allow functions inside classes i barely ever find myself searching for anything by its function name. Its almost always a class name, especially since multiple classes can contain a function with the same name. Also just looking at pure functions usually doesn’t do it for me when examining code, since I also like to see the fields of a class.

Again what the author passes here for revolutionary is a trivial functionality in most IDE’s. In eclipse, you can press Ctrl+Shift+T and type the name of a class, along with wildcards or package names if you want and voila you can get to it instantly. Only this has been possible for about 10 years now…..

No dealing with files

Throughout the demo, it is emphasized that the concept of files is hidden from the user. While good in concept, this is at best a leaky abstraction. At some point you will have to deal with files since that is what your version control system works with. However, almost all ides including visual studio, eclipse and intellij can show you views of your code that contains only the structural elements and not the files. Sure when you go to ‘edit’ the code, it shows you file name in the tab above, but is that really such a big deal….


The demo shows nice little functions calls which have their own small editing area. This seems very contrived. The functions shown are extremely small. How would the editing areas look like if the function in question was long. Wouldnt showing multiple functions on a single surface then lead to a ‘resizing hell’, where you are constantly trying to resize the individual editor windows to see the code you want to see? Sure one can make the argument that you should have small functions, but real world code doesn’t exactly always play by those guidelines.

There is a reason why current ides only allow a split view of editors, and that is to avoid the ‘resize hell’ mentioned above since you only need to resize on one axis at most.

Instant feedback


In this part, which again feels extremely contrived, the author very conveniently shows small functions which operate only on primitive numeral types.

However, real world code rarely works that way. You have objects calling other objects which in turn can call apis which in turn interact with external systems.

How would the instant feedback work on a piece of code that deletes a bunch of files or sends a bunch of emails or is part of a distributed system and n

eeds some input from a network or is complex multithreaded code? I dont want files on my system deleted as soon as I type an api call in the ide, same with sending emails, etc.

The second image here shows a portion of the Chronon Time Travelling Debugger code. How would ‘instant feedback’ work in this case? The code here relies not only on the state of the program in memory but also takes as input external files present on the filesystem. Will Light Table somehow magically generate the files in question and in the proper format that this function expects?

Even if LightTable were somehow to ignore api calls that say, modify your filesystem, how would the IDE ‘know’ about that api. Will someone have to manually go through all the apis in existence and make a list of which ones to emulate and which ones to not? That doesn’t seem practical.

Also even if the code were indeed based on just basic numerical or string primitives, how would the ‘instant feedback’ work if the code were in a long, tight loop or did heavy cpu intensive stuff?


Even though the light table demo looks interesting at first glance, digging deep into it, some of the concepts presented as game changing like ‘documentation everywhere’ and ‘find function’ are already well implemented in other IDEs.

The other half of the demo looks extremely contrived and might look good in a ‘concept’ demo but the examples shown dont seem representative of real world coding and there is no solid explanation of how these problems would be tackled in the final implementation.

Tagged 31 Comments |

31 thoughts on “Light Table: Concept vs Reality

  1. Great post! I think that the people who are excited about LightTable are just excited about IDEs, which is apparently a new concept for them :)

  2. I think Light Table is an attractive concept and Chris Granger seems like a smart guy with a good track record. You bring Eclipse to the table as an example of why things are already good and we should not get excited about Light Table. I don’t think that Eclipse is anywhere near "good enough", and I much prefer Chris’ vision of the future. Chris lists Brett Victor’s Inventing on Principle talk as a source of inspiration. If anyone can deliver a development environment that works even partially like the way Brett’s demos work, they’ve got my support. I think Light Table has the potential.

  3. You act as if the demo is showing the complete product. It is in fact just that , a "demo". For example, how do you know that the docs tab is a "Special docs mode" or that its even intended to work like that in the final version?Too many assumptions, its too early too assume at this point, I think if he can even get 20% of whats being shown in the Demo working in final it will already have come much further in usefulness than most other IDEs, especially Eclipse.

  4. The Light Table demo is using a functional language, where everything is neat and tidy, and there are no side effects in functions. You’re using Java, the definition of unnecessarily complex programming. A function that does disk or network access and complicated operations on data derived from that is generally a bad idea (bad for debugging, testing and adapting to new surroundings).I don’t think that you should change your coding style to work with your IDE, but that’s the main reason why you consider those examples to be contrived. Java also doesn’t work at all with the file-less concept, since it already ties classes to them. I don’t think there is such a thing as an IDE that works well for every language.For example, I tried coding JavaScript in eclipse, but gave up pretty soon because the IDE is so unnecessarily complicated for this task (project management, build system, bad at jumping between many small files quickly, etc.).

  5. 1) The example code isn’t contrived in the caseof functional programming languages. Break free from the constraints of Java & explore that paradigm!2) Could you post a followup review with someone who programs in javascript and is willing to judge the software instead of the demo video of the software? If not…3) Contrived demo video pot, meet contrived review kettle.

  6. anlumo,"""The Light Table demo is using a **functional language**, where everything is neat and tidy, and there are **no side effects in functions.**"""BZZT. Wrong answer.

  7. Great analysis of the proposed ‘new’ features. Even the instant feedback feature is implemented in other IDEs (particularly for functional languages like lisp in emacs). But maybe this project wont be successful because it does something new, but because it does it better. Chris Granger has clearly made a beautiful interface that a lot of people find really exciting. And if it turns out to be as extensible as he proposes, then I’m looking forward to using and modding it.

  8. For everyone piqued due to my misspelling it as ‘piked’, I have now corrected the spelling :D

  9. Perhaps it’s because I’ve been programming for a couple decades now and I’m used to what a good IDE provides as I also did not see anything worth funding in LightTable.

  10. Interesting points. Most of them we have also been discussing in house.A few notes.I think your comparisons of "Eclipse already does that" are discounting that the Eclipse IDE is a monstrosity of complexity, widgets, and "resizing hell". The think the revolution of Light Table for these features is in their usability and hyper-contextual sensitivity.In my opinion, you miss the point of the files issue. Of course this files abstraction is "leaky", because all abstractions are leaky by definition. The idea of removing the distraction of files during development work is to focus on the interplay of the logic. You could say, the reliance on files is actually a side effect of a language/framework/platform being overly reliant on files. Java is among the worst offenders of being overly picky about files and folders. I would levy the same accusation against revision control systems.Your assessment of instant feedback is way off. All this is showing is a debug mode which is always running. All developers program with feedback, usually only available when running the app in debug mode, evaluating variable values, values returned by snippets of code, values printed in the log/console, timing messages in the log, values printed to the output/screen, or even unit testing. The idea presented here is commonly called REPL, is common in scripting languages, and is one of the greatest advantages of interactive shell programming. All of that feedback is live. All of the ways you can see the feedback which was before only available while running the app in debug mode is available at all times. In Light Table, the attempt is not only to show the live evaluations for the code you are editing, but also the downstream/upstream evaluations of other bits of affected code.Regarding your insistence that instant feedback would be a problem when dealing with files, email, network interactions, complex logic, APIs, et al. All of this would also be a problem for unit testing. This is a similar pitfall when you discuss how instant feedback wouldn’t be able handle code which relies on the current "state of the program in memory". Actually, this means you have deterministic code, which is also notoriously hard to test. In my opinion, you are merely making arguments against poorly written code. All IDEs have trouble with this stuff.Thoughts?

  11. You make a few good points here, but they seem buried among a large number of prejudices that sound exactly like what one would expect from a hardcore Java/Eclipse user.First, there’s probably a good reason it intends to support Clojure and Javascript first: both of these languages typically have a REPL and the idea of a printed representation of all objects is perfectly natural. I don’t know why you "assume Java" for the case of showing why it’s weaker than (surprise) an IDE specifically designed for Java.Second, I’m not going to claim that FP is the answer to everything, but functions in functional languages do tend to be shorter than methods in Java, so again, if this new IDE doesn’t work great with Java, I don’t think that’s a fatal flaw. I’ve yet to see any IDE that makes Java into a good language. Alternatively, if this IDE is popular, and strongly discourages people from writing long methods even in Java, I think that would be a great thing.Third, any time I hear something being called a "leaky abstraction" without further explanation of why it applies, I think that label is itself a leaky abstraction. OK, when dealing with version control (step 99 of 100), I have to commit files. Why does it need to show me files for the first 98 steps? Besides, every app that today does not deal with files at all (like any iOS app) did have a predecessor that dealt with files. If this is not inevitable, you need to show why writing software (*not* "writing a Java program") is inherently different from all these other things.

  12. I have to admit I’m skeptical of the usefulness of many of light-table’s features, and the revolutionary nature of any of them. That said, it’s a pretty interface -I’m a PC user, (most of my compatriots at work are mac users) and I see this phenomenon with ‘pretty interfaces’ that focus on one thing over, and over, and over again. They execute one idea very well, but lack fundamental features that one can do without in simple projects, but not so easily in complex ones. As a result there’s a never-ending cycle of installed IDEs on those macs. Personally I think people are addicted to anti-aliased fonts. *welcome to the future!*In the PC arena, stuff looks ugly, so the focus is on features… _tons_ of them. I use netbeans because it’s fast and has the plugins I need (auto complete, un-docing windows to move to a different monitor, good-looking svn, auto complete, inline documentation, etc etc). Eclipse is slower but probably offers even more features.I’ve written some excellent stuff that wasn’t _quite_ complete enough to catch mainstream attention (google "orange-j" as one example)Light Table _could_ become really good for something. Dunno what though. Perhaps they should team up with meteor and get some really nice framework specific mojo going on. That might keep them in the public eye long enough to become a really ‘generically’ useful ide.

  13. +1 to all the comments regarding the functional language.The Light Table dude does say that the concept works well for dynamic languages only. That is an extremely important part to his project, so comparing it to Java/Eclipse will not yield a strong analysis. "The function view is only good for small functions." In dynamically typed languages, coders write small functions to make their code more expressive. Coders are encouraged to keep functions as small as possible, actually, and extract methods whenever logical.On top of that, when you have small functions, providing instant feedback is much more enlightening due to the more focused scope.This is a silly troll.

  14. I think the biggest point that you missed is that many of us (as coders/programmers) have come around in recent years to the idea of elegance and even beauty… I actually made (that noise when you laugh without opening your mouth to let air out ) when I saw that first screen shot. I to have used MANY IDEs over the years that had any combination of autocomplete/introspection/documentation/hinting, etc… but none se elegant as what is describe with lightTable… I’ll agree that you couldn’t simply throw a legacy project at lightTable, as it rewards small, discrete functions.. and seems to punish more voluminous efforts… I look forward to seeing what they come up with… if only to take better advantage of the obnoxiously large screens we are all coding on

  15. I was pretty excited to try it out after seeing the video but I’d really have to try before I buy. I really like the chromeless sleek look of it but the point about how the instant feedback is supposed to be of value in complex apps with external communications seems like a valid concern.

  16. You’re pretty much spot-on. We really don’t need another IDE that pretends to re-invent the wheel. This is just a toy project for someone to have fun with. Serious engineers looking to innovate the IDE should probably focus on writing plugins for existing IDEs.

  17. @zachEvery time someone uses the word "toy" and the term "serious engineer", I want to vomit. These are logical fallacies of the first order. Hasty generalization, no true Scotsman. I’m sure every hardcore C developer would call everything outside of eMacs or vim a "toy". Assembly programmers call C a "toy". Engineers who are serious about the craft continuously evaluate new methods. Existing IDEs are marginal at best. Sometimes you have to slash/burn.

  18. <div class="gmail_extra">Calling a specific project a toy is illogical, but writing off without explanation an entire widely used domain of software as &quot;marginal at best&quot; is ok?</div><div class="gmail_extra"><br> </div><div class="gmail_extra">You decry my use of the term &quot;serious engineers&quot; and then immediately characterize what you think a serious engineer should do. ??So your real problem is simply that we disagree. ??I agree with you that we must [continually] re-evaluate our processes. ??I have re-evaluated mine, and determined that this IDE seems like a waste of time, a reinvention of an already thoroughly invented wheel. ??I don't think it's adding much that is truly new and useful.</div>

  19. The simplest thing is to let them build it, and then see how it survives in the arena of coders. They need to make it as widely available as possible, because the market is used to free IDEs (for the most part). There are a bundle of ways it can fail, and not on technical aspects. It could be revolutionary, or not. I chuckle at the 5-year-old article where the author explained how the iPhone would fail. It was a massive success, but not just because it put internet on the phone. That already existed. It made stuff easy, user friendly, and nicely integrated.In my opinion, if Lightbox can’t handle legacy projects, it won’t be much good because 80% of the time, that is my job: dealing with someone’s legacy project. I’ll shelve it and use something else.If they make it too hard to access from a financial/business/economic sense, then it won’t generate enough momentum to topple stuff like emacs/vim/eclipse/netbeans/intellij. If I have to pay $200 to use it, forget it. I can get something else. If it’s free, then I’ll be highly tempted to see if it saves me time and effort in my day job. So bring it on!

  20. It’s easy to pick apart an idea. There are always PLENTY of reasons NOT to do things. Java is probably the worst possible language imaginable to code in light table. Light table is primarily dreamt up with dynamic, functional languages, the very opposite of Java. Chris lists Brett Victor’s Inventing on Principle talk as a source of inspiration, something that I knew from before, and is very, very excited about. I don’t believe that I will be coding real stuff in Light Table any time soon – the $100 I threw in is more of an adventure into the future of IDEs and programming, to see what we can learn from trying to do something like this.

  21. I appreciate the comparisons with Eclipse. Prior to Eclipse did you ever have the opportunity to use VisualAge for Java (or for Small Talk for that matter)? Many of the concepts from LightTable were there, including managing methods/functions rather than files (including in terms of source control) and changing code on the fly while executing.Eclipse was a step forward in terms of providing an extensible platform that could be adapted to many different things. But VisualAge was way ahead of it in many regards.Just because Eclipse does many things well doesn’t mean there isn’t room for innovation or an open source competitor that has a different take on what an IDE can be.

  22. 3GB ( as fewest with some open projects for Eclipse) and LightTable ( oh wait some web editor, also can be a desktop ) for may be idk 50-100 MB with that features, what are you even talking about, dude ?

  23. i see both sides of the fence. i think the problem is that the push by the developers to make Lightable a product caused the typical reaction tech people have when they try to be product people… make it sound like sliced bread AND the wheel… because its theirs and they love it. so guys like our host here hear/read the buzz and just think its more narcissistic crap, "mine is best because its mine". The gentleman who said a true engineer is always evaluating was spot on. most everything tech was flimsy or leaky before it was crucified to harden it. I may or may not be a true engineer, but i am always looking for what works, and i use the tools that work for what they work for. the last time i used a shoe horn to fix my porch i was sadly disappointed, so i got a nail gun but that just made my feet hurt when i put on my shoes.

Comments are closed.