Last time I identified three Instarepl limitations: invisible intermediate results, hidden recursion, and awkwardly located output with no ability for input. In all three cases, something is hidden or implicit. Light Table is all about making programming more visible and explicit. What can be done to turn the limitations into strengths? Apply an explicitation transformation: visible intermediate results, explicit recursion, interleaved IO.

Visible Intermediate Results

What happens if we insert the value of intermediate reductions below their original expression?

For one thing, vertical spacing is totally messed up! For the two columns to line up, the right repled column now needs to have a say on the layout of the left source column. And once the output is affecting the source, there’s less value in seperating them into two columns. If we give up the vertical constraint imposed by the two column format, what else can we do?

Explicit Recursion

Another limitation of the matched two column format is that you can only easily show one activation of a function since each function is only defined in one place. You could spread out multiple calls or iterations horizontally. Bret Victor demonstraited this for loops. However, we can also unfold function calls vertically:

Here we go three levels deep showing seven fib calls. Too much information? Does fib get messy due to binary branching? Does boxing recursive groups help? Hiding uninteresting parts of the tree may help. Unused conditional branches for instance? Why only a visible and hidden choices? If the recursive steps get smaller, we may get a good overview – or it may just be a mess. Instead of folded dimensions, what would happen if we expanded them? How many axes do programs naturally have?

Interleaved IO

One last idea, not so radical. Instead of putting IO at the bottom, try interleaving it with other expressions:

With a few more text fields and other controls, a kind of UI begins to emerge…