I agree. It's impressive to me the people who are claiming that something like unit testing can compare to these kinds of tools, without seeing the general direction these tools are headed in. Unit tests are helpful, no doubt. But compare the following:

- Spend several minutes writing a small test suite for the functionality you're writing. Write that functionality until you think it's correct. Compile, run. See a "Pass!" or "Fail! (reasons: ...)" in your console or IDE, fix it until it's working. Feedback loop is measured in minutes, seconds at best.

Vs.:

- Write the functionality. As you're writing, you see the data flow through your program in real-time, immediately identifying bugs. Any unit tests you may have are _even more useful_ because you can inspect your program at any level, without having to debug or step through your program. No need to re-compile and re-run, no need to even Alt-Tab. Feedback loop is measured in milliseconds.

Light table isn't quite there yet, but it's a strong step in the right direction. Unit tests help, but they don't obviate the need for better tools.

To give a bit of context on the direction these tools are trying to move in, Light Table was heavily inspired by the work of Bret Victor, who bases his work on the idea that, quote, "Creators need immediate feedback to what they're creating." If you haven't seen his _Inventing on Principle_ talk [0], you should. It's one of the most eye-opening talks on software and design I've ever seen.

[0] http://vimeo.com/36579366

Precisely. Software it's all about shortening the length of the feedback cycle. Chorus: "How is email / web / google different than pigeons / library / index of an encyclopedia book?".

I can't speak for anyone else, but this article didn't add anything that hasn't already been over-hashed on HN already. LightTable has been on and off the front page fairly consistently for the last year, if not longer.

All this article did was make a series of sensationalist (borderline absurd) claims, allude to some new feature or product, and linked to a LT demo video (the content of which is also not new, afaik).

Thus, my personal negativity is not so much a reaction to Light Table itself - but rather the shockingly low journalistic standards of Wired.

FWIW :

My personal experience with Light Table wasn't particularly memorable. I've played around with it on at least a few occasions, but have never really found a true place for it in my workflow (for more than one particular reason - be it developing over layers of virtualization, clunky customization, bugs, etc.).

I'm giving it another shot now, because I can't resist shiny new toys.

I largely agree with you... but then I wonder "how does this deal with recursion, or even repetition", and it turns out it doesn't: it could, I see how it could and it even seems obvious how it could, but because it seems to be trapped in the paradigm of a text editor it simply doesn't handle these cases well, which means that for anything other than simple code you lose this superpower: even at the end of the demo, you see the usage of map means the list-item rendering kept getting its values overwritten by later calls. Frankly, I think this tool is trying to poorly emulate a REPL combined with a debugger in the context of a text editor: you need to see the state of not just the first or last list-item call, but all of the list-item calls. This is then probably why people are somewhat unexcited: while more work, adding a log statement to list-item and getting a trace of the full dynamic execution is actually more valuable and provides better introspection than adding a call to the function in the source code on the left (which is frankly unnatural in the text editor context anyway) and then seeing values displayed inline with the static code on the right. So, maybe they will change their direction in a later release, but this just isn't doing it for me yet.

> REPL is poking at the problem through a tiny keyhole and Light Table is opening the door and shining the light on the full behavior of the code.

I thought there were quite a lot of problems in the algorithms of data structures where you poke around with a hair-pin.