It would be cool to see this integrated with the system used in the backend at Pex for Fun (http://www.pexforfun.com/), which tries to automatically find "interesting" inputs for a function given the code.
Very nice. I'm a bit confused as to how basing this on Roslyn will allow for a MonoDevelop plugin, however. Or did Mono copy the entire Roslyn API, as well?
I've been planning to do something similar, but at run-time where the last known value of each variable is shown. This would complement my stuff nicely - https://github.com/swax/CodePerspective
Just a quick caution from someone who has been building similar tools (not as fancy though), is that runtime instrumentation can often severely slow down the main app to the extent that people often don't want to run such tooling.
There are a bunch of settings where you can define the level of tracking. The state tracking is very low overhead though because it's on demand. So if you run your asp server through code perspective and then deploy it, you can at any time connect to it with the viewer and check out the current state information for all the classes.
I've been using NCrunch for some time now, and really enjoy the instant feedback it gives on failed tests. It constantly chugs away in the background like a faithful dog.
I can see things like Instant C# meaning I have to build less: a great productivity enhancer.
There's lots of places we can take this, which is why I categorize it as a research project.
Being able to create unit tests from this, or being able to look at calls from unit tests here has definitely been on my mind. The way you enter the "test code" right now is not ideal in the slightest as I talk about in my post.
How would Instant C# scale up to real code? What about that bank application that has the side effect of throwing 100$ away from your account on each execution?
Side effects is definitely the biggest problem to solve here. For SQL you can start a transaction and roll it back afterwards. Disk access can be done with snapshots. Network traffic... well I guess it depends on what you're doing exactly. There's lots to do but it can work.
The trick is that you simply wouldn't use this on code where irreversible side effects take place. I think there's enough methods you write where this would help to make it still useful and worthwhile. Tackling the side effect issue is far, far too big of scope.
1) for coordinates and graphical shapes
2) so that it works both ways, i.e. from code to visualizer, but also so that manipulating makes it possible to change the code.
23 comments
[ 574 ms ] story [ 1492 ms ] threadJust a quick caution from someone who has been building similar tools (not as fancy though), is that runtime instrumentation can often severely slow down the main app to the extent that people often don't want to run such tooling.
I can see things like Instant C# meaning I have to build less: a great productivity enhancer.
Being able to create unit tests from this, or being able to look at calls from unit tests here has definitely been on my mind. The way you enter the "test code" right now is not ideal in the slightest as I talk about in my post.
How would Instant C# scale up to real code? What about that bank application that has the side effect of throwing 100$ away from your account on each execution?
I see this as a nice stepping stone in between coding and creating and creating unit test.
I have been a fan of Bret Victors work, but the video here has gotten me really excited.
1) for coordinates and graphical shapes 2) so that it works both ways, i.e. from code to visualizer, but also so that manipulating makes it possible to change the code.
See http://www.youtube.com/watch?v=LpPwjB46E5I for an example of how this works in practice (look around 1:20 in the video)