RE: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1545813427072200?thread_ts=1545720056.038800&cid=C5T9GPWFL (Warning: Contrarian Take, Coming In Hot!) And yet, in so many other fields, the moment of creation is far removed from the moment of reaction, and it's fine. When I paint a painting, I'm not going to get feedback from my audience (or any buyers) until after the painting is done. Some painters might benefit from getting that feedback throughout the creative process. Most (myself included) would surely find it stifling. Point: It is at least conceivable that there are benefits to the lack of immediate feedback when programming. It'd be interesting to try to spitball what those benefits might be. It requires a broader sense of "feedback" than just "does it compile and what does it do when run?", which is of course a broader sense than the one @shalabh intended, but worth considering because we're all here exploring that broader space.

Cheers, @Ivan Reese - I think this is an incredibly interesting line of speculation. It reminds us that most of our current arguments are "fish talking about the absence of water" arguments - that is, we yearn for feedback largely because we don't know how to get it and have never had it, rather than having a clear-sighted view of when it is appropriate and what it is good for. All I can connect it to at present is the "Spectrum of Forgiveness" point in my "Not a Craft" paper of 2016 - https://github.com/amb26/papers/raw/master/ppig-2016b/ppig-2016b.pdf . This looks at some other qualities than responsiveness that we also don't have, in this case, durability and malleability, and places some real materials on a spectrum with respect to them. This appears in section 7 of the paper, and when I presented this it got illustrated in slide 15 of this deck - https://docs.google.com/presentation/d/1Lnt-5Ht7MSj52tVDgOow0HVN94ifnQDhOWjaTMvIy2M/edit?usp=sharing . The preso was a bit disingenuous in suggesting that "more forgiveness is better" given that obviously lots of people do work in ceramics and appreciate the lack of forgiveness of the materials, perhaps largely since they get a lot of durability in exchange for it. Our predicament in software is that all the tradeoffs are currently terrible - we work in a material which is simultaneously unforgiving, brittle and unresponsive - no wonder we yearn for being able to move along any of these three axes : P All the while convincing ourselves that we are "wizards" and can think far better than the general public.

Interesting discussion. I agree that feedback isn't all good, it might be irrelevant or worse, misguiding. I feel thinking of 'feedback' isn't complete without considering the context of the 'medium'. I'm still trying to refine this notion, please pardon the rambling below. In the canvas/painting 'medium', the feedback is that you immediately see visible paint on the canvas the moment you touch it with the brush. We've had shifts from little feedback to more feedback and indirect manipulation to direct in the past. For instance, the shift from line editors and teletypes to interactive screens. The medium here is the document metaphor - which still existed with line editors, but editing was so tedious back then - commands to switch the current line, not having a live view of the full document in front of you, etc. In this case I can't think of downsides of 'more feedback'. Perhaps with less feedback, more thought went into getting a good design the first time and favoring economy of keystrokes, local reasoning? In any case, no one misses the teletypes (I hope 😄) Today the text document editing experience itself is very responsive and direct. You immediately see characters as you type, in the full document. This is great when the document itself is the final product (Google docs) but for programs, we realize that the document is only a means to indirectly manipulate some other system behavior. So we introduce the idea of a feedback loop (edit document -> view final behavior) that we try to optimize. Instead, could we imagine a different medium that we project the system behavior onto, such that it could be manipulated more directly? I agree with @Bosmon here - we don't really know what we don't have. Maybe 'fast but narrow feedback' might work for us because we can't really hold too many moving parts in our heads. In the end I think whenever I'm looping through a series of steps in my workflow, there is an opportunity of seeking out a better medium.

Great thread! I’ll add a few points about feedback. First, in other domains such as motor learning, it is well known that ‘continuous concurrent feedback’ can be counter productive, e.g.: http://hp-research.com/sites/default/files/publications/Schmidt%20%26%20Wulf%20(1997,%20HF).pdf The reason often given is that when the feedback in question is not ‘naturally in the information environment’, it becomes a crutch that when taken away causes failure. Imagine for example a child learning to ride a tricycle with stabilised wheels, versus a bike with no pedals that they learn to balance with by lifting their feet up. Other reasons given include that feedback can interfere with the development of what are ultimately “feedforward” skills. Another thing to consider in this case, is what people in design refer to as “talkback”, which is the generative nature of say a sketch on paper that means it gives back to you more information than you put into it, and that information may be self-contradictory. For example if you sketch a chair and draw over the lines again and again, your brain can then play around with which is the “correct” set of lines, or even imagine ones that aren’t drawn. Feedback in live programming does not entertain these imaginary/self-contradictory paths because they cannot be run as programs, and so the overall “talkback” is limited. Ironically, when there is no feedback, i.e. the program is not running, it may be that the talkback is much greater because the programmer can run bits of code in their head, consider different routes, sketch code they know does not work, receive ideas back from it, and so on. I think this is a good way of explaining what @Ivan Reese is arguing for. More on sketching: Masaki Suwa and Barbara Tversky, “What Do Architects and Students Perceive in Their Design Sketches? A Protocol Analysis,” Design Studies 18, no. 4 (1997): 385–403 Alistair McGown, Graham Green, and Paul A. Rodgers, “Visible Ideas: Information Patterns of Conceptual Sketch Activity,” Design Studies 19, no. 4 (1998): 431–453 Masaki Suwa et al., “Seeing into Sketches: Regrouping Parts Encourages New Interpretations,” in Visual and Spatial Reasoning in Design, 2001, 207–219.

@shalabh said

In the canvas/painting 'medium', the feedback is that you immediately see visible paint on the canvas the moment you touch it with the brush.

The kind of immediate feedback you get from wet paint hitting the canvas is the same kind of feedback you get from your finger hitting a key causing a glyph to show up on the screen. It's very different from the sort of "holistic vision" feedback we're craving, which is why I'm interested in the idea that we should choose what sorts of that feedback we really want, and perhaps be cautious about craving all kinds of it. • Immediacy — The color and texture of paint on the palette as you mix it, the feel of the brush picking up that paint, the feel of the brush on the canvas, the color of the paint as it comes off the brush, the color and sheen of the paint sitting wet in place, the color as it dries • Visibility — How the overall composition of the painting differs from what you had planned, how the composition looks from different angles, how it looks in the mirror, the tint of your studio lights, what you remember of it when you aren't looking at it • Collaborative Editing — Bringing a family member down to your basement studio to look at the painting in progress, sharing a picture of the WIP online, talking about issues with your painter friends • Review — Hanging the finished painting in a gallery, drinking wine and talking about it at the opening, overhearing gossip about it when you later visit the gallery, reading a writeup in the local arts paper, the inevitable disappointment when the painting doesn't sell • Version Control — Deciding to change your style to better appease the kind of audience that comes to the gallery, burning the painting in a parking garage while drinking beer with those painter friends Every single one of those examples of feedback would be affected if you switched from oil to watercolor — and switching from one programming tool to another affects as many kinds of feedback too. The notion of "feedback" covers every surface of a tool, including your mental model of it, the social dynamics, the learning process — and changing the way in which a tool gives feedback touches all these surfaces.

@Ivan Reese said

The kind of immediate feedback you get from wet paint hitting the canvas is the same kind of feedback you get from your finger hitting a key causing a glyph to show up on the screen.

Yes, I did a poor job explaining what I was trying to get at. It's related to what you describe as 'visibility' - the whole composition is immediately updated and visible when the paint goes on the canvas (at least from the current perspective). Imagine painting through a peephole, only seeing a part of the painting and having to imagine the full composition. In the specific aspect of visibility at least, it seems one full composition should be always visible when being updated. Onto programming.. the code if visible and updated live, but code isn't the full composition. The full composition is some behavior spread out over time and within a slice of all possibilities. We imagine it (human simulating the machine) and it is not visible in the editing medium. I think it's the idea of reducing/eliminating mental simulation of the computer that I find more important than 'feedback'.

we should choose what sorts of that feedback we really want,

Fully agree with this. I think choice of 'viewing perspective' should be natural in the future medium of programming - one simply cannot process all possible perspectives available anyway.

the whole composition is immediately updated and visible when the paint goes on the canvas (at least from the current perspective)

True, but the artist's understanding of the work isn't updated immediately. You often need to spend some time away from the painting, and come back to it later "with fresh eyes" to properly appreciate the meaning of any changes you made. Same with music — when I'm working on a song, I'm in a very particular mindset, one which is not amenable to appreciating whether or not the music is any good. The sort of feedback I get from throwing some additional paint on the canvas, or tweaking a melodic progression, is akin to checking whether my tests are passing — I can tell whether the things I've done are correct or erroneous, but I can't actually run the painting or run the music to appreciate whether it works the way I intended until after some time has passed. My point is that.. when we programmers talk about immediacy, we love the example of artists getting immediate feedback. But I contend that it's a faulty comparison. Artists don't get immediate feedback about the most important part of their work: whether the work is effective or not. They do get immediate feedback about some technical / mechanical aspects, though even this doesn't hold for some art forms, like pottery, where you need to bake the clay in a kiln before you know if it even survives that part of the process.

@Ivan Reese - I realize I've been pulling the conversation to my earlier, narrow (engineering?) perspective of the creation process (in spite of your note about the 'broader space' in the first post).

True, but the artist's understanding of the work isn't updated immediately.

Artists don't get immediate feedback about the most important part of their work: whether the work is effective or not.

Great points. There's been times in programming when the next morning I realize I was moving correctly but in the wrong direction. I'm wondering how one could get a sense of something being effective. Improv forms are interesting because there's the back-and-forth conversational aspect. Even live compiler feedback is more like a partner that only responds with 'yes' or 'no'. Perhaps richer responses are possible if instead of submitting whole programs, we build incrementally by sending one message at a time and the computer responding with a wide range of possibilities for us to explore next.

I’m glad you mentioned “the next morning”. That’s one aspect that’s definitely shared between programming and all the arts — reflection, outside the heat of the moment. My hunch is that the arts have a richer variety of “next morning”-style means for reflection (eg: the group crit idea mentioned in the other thread), but that might be because it’s unfair to compare all the arts to programming. In any case, that “build incrementally” process is a big thing in live coding (I’d argue, by necessity). But the “responding with a wide range of possibilities” isn’t really something that I’ve ever seen. I’ve heard people talk about ideas like this, but never framed in terms of improv. I really like the idea of a programming system designed to be like an improv partner, throwing out ideas for you to “Yes, and...”