PANE 🌇

The most significant inspiration for PANE is Jonathan Edwards’ Subtext series. Subtext established the vision of data-centric live programming which this project follows. Many basic mechanisms in PANE were taken from Subtext either directly or indirectly, including:

• building abstract functions using concrete examples
• linking objects based on identity rather than name
• "expanding" views of function calls

PANE shares a real kinship with Conal Elliott's Tangible Functional Programming. Both are built off of functional foundations. And, more uniquely, both are centered around showing concrete values and using them as handles for direct construction of programs. Two important differences between the PANE and TFP:

1. When a user of TFP composes two functions, they get a black-box function which (quite intentionally) hides the implementation. PANE, on the other hand, is an attempt to present the internals of functions in a legible and modifiable way.
2. Elliott argues against box-and-arrow representations, as they create a distinction between functions and values which doesn't fit higher-order functional programming styles. So far, PANE has side-stepped this concern by building in box-and-arrow representations of a few higher-order operations (like map and filter). For PANE to go further than this, it will have to find a more general way around Elliott's concerns.

Spreadsheets are a clear precedent for any live data project. In particular, I would like to call out Glen Chiacherri’s Flowsheets project, which explores how to give spreadsheets the power of conventional programming, while maintaining the immediacy and casualness of the good old grid. PANE aspires to this same blend of power and immediacy.

Lamdu is a Haskell-style functional language which gives live feedback about intermediate values. It is taking a different, more syntax- & type-driven, approach than PANE is. But it seems to be following similar principles and I am excited to follow its development.

PANE has invited comparison to notebooks, especially live, reactive notebooks like Observable. But so far, the visibility that Observable offers programmers has not been fine-grained enough to create the sort of experience that PANE aims for. As a simple example: the moment you take a block of code in Observable and make it into a function, or put it in a loop, its internals become completely invisible. It remains to be seen if the Observable developers will try to push past these limitations.

A final, intriguing case is Luna, a node-based language built on strongly-typed functional foundations. Its similarities to PANE are very clear, including a focus on “data-processing” and visualization, and a similar grounding principle. But it is worth noting the differences. For guidance, we can look at the two design choices that shaped PANE’s development.

1. Foreground the data: Luna makes visualizations accessible, as annotations on nodes, but it does not make them visible by default, or make them the main handle for manipulating a program.
2. Use hybrid metaphors: Luna offers two representations of a program, as a node network or as code. But these are parallel, not hybrid. The node network is a traditional node network, and the code is traditional code.

It will be exciting to see how the choices made in Luna’s design work out, or evolve.