Making Instant C# Viable – Visualization

Making Instant C# Viable – Part 1
Making Instant C# Viable – Part 2


I’ve spent a lot of time talking about how to actually make it work, but the internals could be perfect and the project would be worthless without a viable way to visualize the information. In Bret and I’s original prototypes, everything is simply dumped to text next to the code. However, certain elements (such as loops) do not fit in a single line in this manner. As a result, they do not scale to some real scenarios, such as loops with iterations in the thousands.

As I’ve stated before, the primary goal is to end up with a plugin for Visual Studio and MonoDevelop that provides the Instant functionality. With that in mind, we need to start exploring what this might look like inside of an IDE. Even discounting the existing limitations, I didn’t feel that a fixed box of text next to an ever shifting block of code would really fit well inside the existing IDE experience. My jumping off point for a new visualization came easily, as both IDEs already support a feature that pins values of variables in the code window, but only while debugging:

Pin to Source
Pin to Source

So, with that in mind, I started to retrofit the prototype with a similar system. However, my favorite screen recording tool (Jing) wasn’t working on Windows 8 – a perfect excuse to procrastinate. Once I noticed Jing was updated finally for Windows 8, I started to work on polishing up the prototype to blog about. In that process, I noticed there’s a Visual Studio template for editor extensions. I’d been putting even looking at a plugin until the last minute because learning an IDE’s API would distract me from core problems I’d still not solved. But, now noticing the template, I finally said “how hard could it be?”

Working Demo

Get Adobe Flash player

Not as hard as I thought. As you can see, variable state changes display similar to “pin to source”. Furthermore, you can page through iterations of loops, showing you the state of variables in each iteration when they’re changed. You might also notice that the iteration seems to stop arbitrarily the first couple times I change it, this is due to some behavior attempting to prevent infinite loops (which I’ll get into in a future article).

The Good and the Bad

Now, getting back to the visualization, I consider the advantages over the static side-by-side text display to be that it:

  1. Scales to real code.
  2. Provides a familiar (from debugging) HUD-like view to what’s going on, instead of a separate window to mentally line up.
  3. Provides a lot of capabilities in expansion of the visualization.

There are, however, a number of issues I’d like to address with this. Firstly, the method of entering the “test code” is not ideal in the slightest for two primary reasons:

  1. A separate dialog adds a lot of friction to getting started.
  2. The test code is not adjustable.

The reason this prototype has a separate window for example entry instead of an inline box was simply that I couldn’t get VS to cooperate. As I learn more about the SDK, hopefully I’ll be able to overcome this. Once in an inline form, number 2 should cease to be an issue as well.

The second issue is that you lose a significant advantage as compared to the text display: the ability to look at two iterations side-by-side. Now, I cited this as one of the problems of the text display, but there’s no reason why we can’t do a constrained view. I’m imagining an expanding tip for variables inside of loops where you can display X number of iterations before and after the current iteration being viewed. So this is something we can relatively easily improve upon.

A third issue is that the return value is not displayed, which to be honest is simply because there’s two bugs related to it that I have not found time to fix just yet, but it’s important and will be there.

The Future

I mentioned one feature I’d like to add before, but there are so many more. For example, I’d like to add a display for conditionals that displays both what is being evaluated and the evaluations, something like:

[(2 < 5 || false)  |  (true || false)  |  true]
if (x < 5 || isFoo)

There’s some other simple ones like showing values passed to other methods, and there’s ones I haven’t thought about much yet (but I know will be hard) like different threads. There’s lots that can be done to simply give the developer more clarity about what they’re writing is actually doing.. instantly.

What other kinds of information would you like to see while you’re coding?

Update: The source is now available.

This entry was posted in Instant, Projects and tagged , , , . Bookmark the permalink.

29 Responses to Making Instant C# Viable – Visualization

  1. Toni Petrina says:

    Wow, I just started on my own tool that would enable faster C# prototyping using Roslyn and partial execution only to find this. This looks so much better, great work. I wish that you open source it since I have my own ideas on top of it. Good luck.

  2. Ivan says:

    Could you show a demo in a real project? I’m afraid these kinds of tools are absolutely useless in real life. May be extremely useful in schools to learn the language basics though.

    • Rao Venu says:

      @Ivan: I have to disagree. This is not a tool for visualizing the entire code base like a dependency graph or class hierarchy. It is just a tool to visualize the execution paths of a simple function as you are writing the code rather than stepping through the debugger.
      Not every solution has to be a solve-every-problem-in-the-world kind of solution.

      Nice job @ernau


    • ermau says:

      No, not yet. That’s an important problem I haven’t solved yet, but it’s rapidly approaching on the list. The current issue is that the current execution engine (based on Roslyn’s ScriptEngine) isn’t robust enough to handle anything beyond single methods.

      I would argue that useless point though. Obviously you won’t be using this for every single method you write, but a REPL is even simpler than this and I think it’s safe to say most wouldn’t call that useless. To me, this goes way beyond what you can accomplish with just a REPL. So we’re on the same page, I see full project support as being able to use the types and methods from your project and not having this running everywhere all the time. I would agree that that kind of support is critical to this not being relegated to when you’re writing binary search or similar things.

  3. Xerxes says:

    Can’t help but notice the GH repo hasnt been updated in a couple of months.

    Will the vis work be pushed up anytime? Would love to play around with it…

  4. This looks awesome!

    I have been using Roslyn/C# Interactive for Exploratory Data Analysis, and the main thing it is missing at the moment is inline visualization support.

    Any reason why what you have done will not work in CSX files? In that case, you don’t have to worry so much about providing “test code” as the script is typically self-contained. Being able to see each inline value (with a customizable visualizer) would be extremely powerful.

    Once you have this on github we would be happy to help enhance it.

    • ermau says:


      Given that the current execution is based on ScriptEngine, we basically are running on CSX files, just without saving them. The engine will change to something more robust in the future, but I plan to keep the execution engine separate so that it can be swapped out (originally so something like Compilify could do some integration, but this would support using CSX as well).

  5. This is pretty darn impressive, Eric.

    …what other limitations are there to this as of the moment?

    • ermau says:


      I mentioned the biggest one in a previous comment, the fact that it doesn’t work beyond a simple method. Another is that you would never want to use this for methods with serious side effects. It’s just too large of a scope of problem to solve and I don’t plan on attacking it. And the last major one is that it’s currently based on Roslyn.. which means I can’t ship it in an extension, nor can I put it into MonoDevelop.

  6. Marc Brooks says:

    Wouldn’t it be best to drive people toward test driven development and make the “test code” be actual code that you enable/chose which test to run while in active-coding mode. Then people could easily see the test code, easily edit it, etc…

    • ermau says:

      This is certainly on my radar for different ways of setting up the “invoking” code, I just haven’t gotten to tackling it yet. I think it’s important to maintain a non-test oriented way of using this, but there’s lots of potential for integrating with tests here.

  7. KevinM1 says:

    Impressive. I can see something like this being very useful for me as I always tend to do a final check of my values while stepping through with the debugger. Having them there, in place for me as I code, would be a huge time saver.

    Any chance of this being back-ported to VS 2010?

  8. Fikre Leguesse says:

    This is too good.

    Now that I saw it, I must have it.

  9. Francisco Noriega says:

    That was awesome! I hope you can release a public beta soon!

    And if I add my 2 cents, I think you should try to change the conditional expression evaluation sintax.. using the single Pipe was a bit confusing..

    maybe changing from:
    [(2 < 5 || false) | (true || false) | true]

    to something like
    [(2 (true || false) -> true] ?
    (the -> arrow looks a lot better with the regular vs font though), and the final result bold, so you can spot is quickly

    • ermau says:


      Well, the | was meant to be the blue border like in the existing visuals. I thought about mocking up an image of it, I guess I should have. I’ve got some better ideas than I posted, but I just couldn’t think of a good way to describe it. Regardless, I’ll be trying as many was as I can think of to make things clear, thanks for the input!

  10. This is absolutely rad. Great Job!

  11. Pingback: TWC9: Azure Web rev's, WAMS opens source, Windows 8 Camp in a Box, JavaScript resources - Windows Azure Blog

  12. Aleksander says:

    This. Is. AWESOME! It’s bound to revolutionize the entire TDD culture. And for the better!
    Can’t wait to be able to play with the new version. Keep it up! :)

  13. Chris says:

    Any chance of this hitting MonoDevelop sometime too? I’d love to see this feature reach open-source IDEs.

    • ermau says:

      “As I’ve stated before, the primary goal is to end up with a plugin for Visual Studio and MonoDevelop that provides the Instant functionality.”

      I haven’t actually released the Visual Studio version yet. To get it working for MonoDevelop I first need to port it to NRefactory and then learn the MonoDevelop addin APIs. Sometime, just not soon.

  14. Pingback: Instant 0.1 » Code Monkey vs. The World

  15. NyaRuRu says:


    One thing I noticed is an overflow issue in the sample binary search code.
    int mid = low + (high – low) / 2; solves the issue.

    This article is nice to read.
    Nearly All Binary Searches and Mergesorts are Broken

  16. Pingback: Making Instant C# Viable – Visualization | Teusje

  17. Pingback: VS拡張とか非同期処理のキャンセルとか « ++C++; // 未確認飛行 C ブログ

  18. Pingback: Evolution of coding | Kloud Blog

Leave a Reply

Your email address will not be published. Required fields are marked *