3 ms·
It is both a very nice start, and there is definitely lots of room for improvement. I'm working in this very area too. One other thing I can add is that, IMO,
by shurcooL 14y ago
It is both a very nice start, and there is definitely lots of room for improvement.
I'm working in this very area too.
One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program (the tool should do everything it can to make the process easy, you just supply the necessary inputs).
- seanmcdirmid 14y ago> One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program Sounds sort of like Bracha's stance. I think we should just focus on making the feedback better over an entire program execution. And we could make defining unit tests easy, which would provide the context needed to test smaller parts of the program.
- shurcooL 14y agoCould you please link me to what you mean by Bracha's stance? I think making feedback better over the entire program execution is hard when dealing with immensely large projects. But breaking down those huge projects into smaller pure components with well defined dependencies might stand a better chance. I don't know for sure yet, but I'm gonna try and find out.
- seanmcdirmid 14y agoI just saw him speak about it at a meeting we had recently. He also has something about this on his blog (http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.html http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode....), though I don't think he says anything about that there. I'm trying to write a paper about this right now for Onward, but I think its possible to do large programs with the right amount of incrementalization within. There is definitely a limit though (if the change influences a lot of stuff, there isn't much we can do right?)
- shurcooL 14y agoThanks, that was an excellent read.