Background

We like crosscut

Crosscut feels super promising as an alternative modality for creating programs without typing formulas, and one that feels very natural/well suited to certain kinds of problems—particularly visuospatial/geometric ones.

We aren’t exactly sure what’s great about it—what the key ingredients are. The things I like best are (1) the ideas of meta-ink for expressing relationships/constraints visually and programming-in-the-small, and (2) of “encapsulation without lamination”—feels like the right way to do encapsulation of logic and re-usable components.

Crosscut also has some problems

Main issues to me revolve around being able to intuitively make circuits/programs without having to think about the computational flow—this is harder than it sounds. Right now it’s easy to construct a circuit that doesn’t make sense computationally, can’t be handled by the system, or doesn’t behave as you’d intuitively expect.

I believe part of the problem is that Crosscut has a weak directionality to it—there is a preference in the way the system implements bidirectional behavior (running in reverse) that isn’t always intuitive during construction of programs. Also many of the operators have a “handedness” to them that makes sense when thinking about reverse computation flow, but sometimes doesn’t make sense when making a circuit. For example, if you want to make thing a equal to the sum of things b and c, you don’t want to have to specify which of b and c is the thing that’s being added versus the thing that’s being added to, they feel equally important and you would expect that if you change a, the change would propagate into both b and c in some way (split equally or perhaps proportionally), not that all of the change would be pushed into arbitrarily one of those letters, or that you would have to explicitly decide which one at the time you are constructing the program. This is analogous to the difference between the expression a + b = c + d and a = c + d - b. While they are algebraically/computationally equivalent, the former is meaningfully better than they latter in that it represents more closely the relationship you are trying to express whereas the latter implies a point of view, that a is driven by the others or that we should view the problem from the perspective of a or that we are saying something slightly imperative about the order in which the calculation should be performed, which we don’t intend to say.

This feels like a bad middle-ground of weak/implicit directional preference, where it would be better to either be much more neutral and truly bidirectional, or be much more explicitly directional.

Key Goals

Biggest questions to me are (1) how do we get out of the bad middle ground by either going more toward true/better bi-directionality, or more toward explicit locked-down directional flow, and (2) how we combine this modality of drawing programs on the canvas with the declarative/reactive/dataflow/formula style of expression we love from spreadsheets and we hinted at with Inkbase.

One idea is to allow mixing both Crosscut-like circuit diagrams/meta-ink on the canvas with Inkbase/spreadsheet-like property formulas, and allow us to translate back and forth between them—you could wire up a diagram and then see it represented as a formula when you look at any of the involved properties. Could this be combined with a more bidirectional system where you can write a relationship with a formula or a circuit and then see that relationship rewritten from the perspective of a given variable? For example you wire up a + b = c + d, but then you can go into property a and see it’s value set to c + d - b, or into c and see it set to a + b - d.

Simultaneously with exploring these ideas I was thinking about allowing setting and retrieval of arbitrary properties, being able to scope properties not just to points but also to line segments or paths or groups, etc., and about how an Inkbase-style property pane might interplay with Crosscut circuits—being able to drag properties onto the screen to get meta-ink lines with property pickers already attached (a la EToys) or dragging values to get labels already wired up to the right property picker, truly bidirectional/non-handed operators a la Fabrik, and how to design components so that you can specify not only which properties are public vs private but also which concrete ink lines are visible and what the interface is for snapping/merging/inserting into a larger drawing, perhaps with recursive setting of points a la ThingLab.