With all of the demos and information posted I still have trouble visualizing this working for real-world applications. A specific example: in the Python/Flask demo, functions were added to the current view as it was called. How would this work in a more complex case with calls to many functions, each which call many more functions (and so on), each belonging to different objects, etc.? The view would quickly become a huge list of functions and code blocks, most of which you probably don't need to see at any given time, and at this point it's no more useful than plain old user-curated tabs.
That's just one example. The same conceptual problems pop up for stuff like on-the-fly code execution (what if your code depends on user input or many SQL queries or files that may or may not exist at that point), benchmark mode (benchmarking a complex app is obviously a lot more complicated than just running two code blocks side by side), etc.
I know this is just a demo and it's all very early in the process, and I'm not saying that this should be a solved problem yet, but I just can't picture in my head a way that this could ever be a solved problem as long as LightTable remains somewhat similar to its current state.
Right now it goes at most one level deep into the call tree to prevent what you're talking about. The thinking I've had so far is that you then have a few options. You could go to one of the specific functions and say I want to see everything, you could go to a specific token and bring up its definition, or you could "focus" it to switch the starting point to that function. I think any of those could work, but I haven't tested them yet :)
To your second point the normal caveats of a replish environment will apply to any code execution stuff :) And the benchmarking mode was a simple example for working against functions once you already know they're the bottleneck. In a real application you probably need help getting there.
I agree and I think a big part of the job ahead is to understand how we can ensure these sorts of experiences mesh and flow together when working on something larger. Fortunately, Light Table itself provides a great project to prove that on.
They could display it as a graph with function names like a call stack. Most IDEs support most of the features shown in a piecemeal fashion but Light table seem to have the features more integrated, reducing the friction between coding and testing.
That's just one example. The same conceptual problems pop up for stuff like on-the-fly code execution (what if your code depends on user input or many SQL queries or files that may or may not exist at that point), benchmark mode (benchmarking a complex app is obviously a lot more complicated than just running two code blocks side by side), etc.
I know this is just a demo and it's all very early in the process, and I'm not saying that this should be a solved problem yet, but I just can't picture in my head a way that this could ever be a solved problem as long as LightTable remains somewhat similar to its current state.