PANE slaps so hard. Of course, his “you can’t see the data in the wires” at the end is a bit of a cheap shot — anyone with the skill and imagination to build something like PANE could solve that particular shortcoming.
I feel so much resonance with his goals, and the exact choice of shortcomings... but it’s wild to me that the design he pursued is so different from the one I’m pursuing. For such a seemingly tightly-defined problem domain — visual programming tools vaguely inspired by FP and patching that radically show data — the solution space is vast!
What I wonder is.. what choice of programming operations / style best lends itself to the visual presentation in PANE? Mapping a list seem like a great fit, but what about reduce? What about higher order functions, or currying? What about place-oriented procedural programming, with some spreadsheet-like data types? Something I loved about Bret Victor’s Drawing Dynamic Visualizations was the different paradigms for different parts of the job. I feel like that might suit PANE well — and I think Josh’s thought at the end about integrating with Apparatus is a pang for that.
06/24/2019, 3:09 PM
http://aprt.us/ here's a link to the absolute Unit that is apparatus (also hard to google)
06/24/2019, 5:09 PM
@Joshua Horowitz is in the Slack, maybe he can answer some of your questions