[richardk]

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?

I think this is a critical point, has the author of LightTable considered what would happen with instant feedback for less trivial pieces of code?

Besides that, I think this critique is fair, because honestly when I saw LightTable, it seemed like smoke and mirrors. I have a friend quietly writing an innovative new text editor, I expect it will be more 'ground-breaking' than LightTable, but I don't see him trying to take everybody's money.

[Zak]

I think this is a critical point, has the author of LightTable considered what would happen with instant feedback for less trivial pieces of code?

Some of the code in his demo talked to the web framework he wrote (that I use in production code) and IIRC to the SQL abstraction layer he wrote (that I also use in production code). Something makes me think that he has given some thought to how these things might interact with the real world.

I think it's fair to ask for money. Chris Granger has a track record of building useful, production-worthy libraries and tools both professionally and as a hobby. If he's going to not work for a while, possibly hire other people and build an open source IDE, it's reasonable to ask for outside funding.

[richardk]

I'm not sure about others, but I wouldn't give my money to any software project that didn't describe in detail how it might overcome such glaring design challenges.

[Zak]

You seem to be focused on the instant feedback and stack display issues.

Instant feedback is not meaningfully different from a REPL in this respect. It is unlikely you would type imperative things like "delete this directory" in to a source file. You might define a cleanup function that deletes files, but it would be pretty unusual to call it at the toplevel unless you were intentionally using the code buffer as a REPL. I'll grant that immediate evaluation of such things might be a little dangerous, but Clojure, though the JVM does have mechanisms to dangerous things like file IO.

Stack display seems like an easier problem to solve: only display a certain depth, or just put a scroll bar on it. It doesn't matter how much stuff there is as long as you're looking at the part you're likely to want by default.

I think the one downfall of this project as currently envisioned might be that this is a great concept for Clojure and perhaps some other functional languages. It could be good for JS if written in a mostly functional style. Python is a little less functional and is commonly used for scripts, which wouldn't play as nicely with instant feedback.

Scripts are distinct from applications or daemons in that they normally contain a sequence of imperative actions that they evaluate and then quit. They might not define any functions at all. Applications and daemons typically run code from an entry point like a main() function. LightTable seems to be designed with Clojure in mind, and Clojure was not designed with scripts in mind.

[richardk]

I'm not familiar enough with Clojure to comment.