Skip to content
Philip Guo edited this page Dec 16, 2015 · 15 revisions

This page documents the initial design of the Rosetta runtime code visualization toolkit, based on experiences and notes collected over the past few years.

Created on 2015-12-16 by Philip Guo

Overview

Rosetta aims to be an expressive toolkit for creating runtime code visualizations like the ones that power Python Tutor. Right now the Python Tutor visual primitives and layout algorithms are hard-coded in JavaScript with a hacky mix of d3, jQuery, and jsPlumb. I wrote the current viz code back in 2011, with some tweaks in 2012.

There is only one canonical visualization format (with a few select variants for power users), which works fine in practice but is nearly impossible to customize for different pedagogical use cases. Right now it's "here's your visualization, if you don't like it, too bad!" I've managed to bolt on support for other languages such as Java, JavaScript, TypeScript, Ruby, C, and C++, but the viz code gets increasingly hackier with each new language. This "ossification" in the current code base precludes future innovations and research contributions.

Thus, I want to take what I've learned from the past 6 years of Python Tutor usage and leverage that experience to create a more expressive toolkit for exploring future runtime code visualization ideas. The ultimate dream is to be able to use Rosetta to easily build any kind of runtime code visualization for any language for the purposes of both learning and production-scale debugging. A more realistic dream is to simply target general-purpose imperative and OO languages, and to focus on the learning use case; in other words, to replicate what is already possible on Python Tutor, with a substantial cleanup of the underlying viz code base to make it more general-purpose and extensible in the future.

One major inspiration for Rosetta is Vega and related toolkits by Jeff Heer's group at UW.

Primary Design Goals

  • Multi-language: must be expressive enough to create visualizations in many general-purpose imperative and OO languages such as Python, Java, JavaScript, Ruby, C, and C++
  • Polymorphic views: an object in the target program must be able to be visualized in different ways. For instance, a C string may be viewed as either a string literal, an array of chars (i.e., letters), or an array of bytes (in decimal, octal, hex, etc.). A Python/JS/Ruby/etc. object instance may be shown either as its constituent fields or pretty-printed using its toString-like function.
  • Visual transitions: show what has changed or will change between two consecutive program points, either via simple fade in/out, colored outlines around relevant objects, or unified diff (diff -u) sorts of views. this feature is crucial for helping users grok changes, although it doesn't need to include fancy animations.

Secondary Design Goals

These features are nice-to-have but not mandatory:

  • Scalability: for production-scale debugging, it would be nice to scale up to larger data that cannot fit on a whiteboard-like surface in the real world. e.g., compressing a 10000-element list into, say, a line chart, then allowing the user to semantically zoom. also selectively showing and hiding objects on-demand so as not to overwhelm the user.
  • Animations: showing how objects mutate by animating motion is a nice gimmick, but my hunch is that it doesn't add much beyond simple visual transitions, which is a primary design goal
  • Functional and dataflow programming: it would be cool to also visualize functional or dataflow languages in addition to the state-based visualizations optimized for imperative/OO languages

Implementation ideas

Possible building blocks: React, jQuery, jsPlumb (for arrows)

Not sure if d3 is the right level of abstraction here, though. However, ideally I'd want something that can animate state changes so that the user can see what has changed between two consecutive states. d3 does this well, but does React do this?

Clone this wiki locally