Feeling of Computing • Episode 80 • Technical Dimensions of Feedback in Live Programming Systems by @Joshua Horowitz The podcast is back!! Woof this one took a long time to edit. But, the good news, the good news: this paper is a banger, and I'm not just saying that because I've gazed longingly into Josh's eyes (and I'm not saying I have done that, either). More good news — several of you probably know that this paper is a banger, for reasons that will become clear to the rest of you as you listen. (Have I said too much? Is it too easy to figure out all these secrets? Keep mum.) What's the paper about? I mean… you have live programming systems. They give you feedback on your program as you edit it. The design of the feedback mechanism(s) is an interesting space to explore, and there are tradeoffs and (Margaret) qualia to balance and stretch and enrich. In the paper, Josh maps out the space and gives us hints as to how to make live programming systems way the hell better. Personally, I left this paper wanting feeling super jazzed to go make even wilder visual programming systems. Hopefully you'll find it similarly exciting. And I hope you enjoy the podcast. Let me know what you think — sincerely.

In a system where feedback is highly material, would that make it difficult to remove the feedback when making the system available to a "user" instead of a "programmer" since the rest of the program now depends upon the feedback system? If the feedback is also bidirectional, could that blur the line between a "user" and a "programmer"?

I hope the answer to both is "yes", because I think this aligns incentives in a way I want. I want more software to be modifiable from outside, and I want more kids to tinker.

@Personal Dynamic Media I think “yes” to both, to some degree. The two examples I give for materiality are systems (Etoys, Boxer) which presume the user is the programmer & which don’t provide any way to run programs outside the editor. Strictly speaking it doesn’t have to be like this… You could imagine a Boxer-like environment where you could write a server to respond to API requests. When serving that function, it wouldn’t be showing any feedback to anyone. But the programming model would still be designed around naive realism, and when a developer went in to debug some malfunctioning response, they would benefit from the everything-visible-by-default design. Kinda an interesting thought, for those willing to unforgivably debase Boxer’s vision. (/s?) I think a big motivation behind bidirectional projects (straightforward bidirectionality like Sketch-n-Sketch, or PbD systems that I lump in there) is to enable programming using interaction techniques familiar to everyday computer users, especially direct manipulation. That can blur lines between users and programmers in terms of who has the experience to work with the programming system. It also (subtle difference!) can make using the programming system more continuous with using a direct-use system — the systems might be unified, letting activities cross back and forth between this boundary fluidly. We were aiming for something like this with Sculpin (paper, ), and I guess I sorta talk about it in my Blurry Boundaries paper.

Great show!

Fun episode!