5 ms·

I may understate Bret Victor's thesis and may overstate Josh Varty's counterargument but I believe JV's criticisms are not applicable to BV's particular essay.

by jasode 11y ago

I may understate Bret Victor's thesis and may overstate Josh Varty's counterargument but I believe JV's criticisms are not applicable to BV's particular essay. Some key quotes from each for context: >Bret Victor: "How do we get people to understand programming?"[1] >Josh Varty: "Problems getting to Learnable Programming [...] However, we need to stop and think deeply about how this system would handle typical code. How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? The vast majority of functions in today's codebases do not map nicely to a 2D output." I see BV's essay focused on learning programming for people unfamiliar with programming. For non-programmers, even simple syntax such as "x=0; x=x+1" looks strange and beginners can't hold in their head what it does. So instead trying to teach beginners the LOGO programming language to move turtles around on the screen or BASIC language of "10 PRINT "HELLO" \n 20 GOTO 10", Brett shows a visualization where code syntax update its 2d output in a realtime feedback loop. This can help novices make the leap from abstract syntax in a text editor to the concrete changes in the output. Josh Varty is going beyond the scope of newbies learning programming concepts. He's trying to generalize it to working practitioners who already understand programming and make the "Learnable Programming Model" work for any arbitrary code to any type of visualization (beyond 2D if necessary). The "live coding for everything" is an interesting concept to pursue but I don't believe Brett's essay had this wide of a scope. I don't believe working programmers who have already mastered how "programming syntax maps to changing machine state" needs visualizations for every line of source code. However, JV's generalized scope is applicable for working programmers to verify code for correctness and do sanity checks on what they think the code is doing.[2] However JV's ideas are not necessary for working programmers to understand programming. In one case, JV uses this as example: var result = DoTaxes(person); The professional programmer (not the "learning programmer") doesn't need a clever realtime visualization to "understand" DoTaxes() in the BV sense. The programmer already has some idea that it probably has some code that performs multiplication and addition. Possibly even a lookup table for different countries or taxing authorities. The realtime visualization would help the professional programmer verify what the code actually does. Since realtime isn't available today, programmers get by with watch windows in visual debuggers, or manually insert printf()/console.log() statements. However, the programmer doesn't need BV visualizations to grok the compsci topics of the changing machine state inside DoTaxes(). tldr: BV and JV are tackling 2 different issues. [1]http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ [2]See how JV's ALIVE demo visualization serves a different cognitive function from BV's. Those little red annotations are helpful for professional programmers to verify behaviors but not for beginners to grok compsci: https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif

Permit 11y ago
I actually wondered the same: Are these ideas meant to apply more broadly to programming in general, or are they a framework for learning? So I reached out to Bret on Twitter: https://twitter.com/ThisIsJoshVarty/status/631562151728025600 https://twitter.com/ThisIsJoshVarty/status/63156215172802560... (I see now he's deleted his Tweet...) In his response he told me to read the section "These are not training wheels" near the end of the blog. Here he says: >A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is a reasonable question, but it's somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. >Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming? I think the ideas he explores can apply more generally outside of creating environment for learning. And my understanding is that Bret believes they should apply to programming in general as well.
- jasode 11y ago
  >And my understanding is that Bret believes they should apply to programming in general as well. Yes I agree, but I think his 2D visualizations that you criticized were focused on "learning programming".[1] BV wasn't saying that extending it into "non-learning" scenarios for professional programmers must be a 2D feedback loop. Consider a new programming language with specialized syntax or a library of functions for moving a physical robot in 3D space. The feedback loop could be a live Bluetooth or wifi connection to a articulating robot arm on the programmer's desk. I wouldn't think BV would criticize that and say, "no, the robot arm must be 2d image on the screen". [1]key phrase of "presented in context for learning" from BV: "These design principles were presented in the context of systems for learning,"
  - jules 11y ago
    The problem isn't things that we know how to visualize but do not fit the 2D model, the problem is the things that we do not know how to visualize well (which is most of the data in our programs). Visualizing the output of a program that does a 2D drawing is easy, because it's already visual. The hard part is doing it for general programming, and the essay is handwaving around that. I think the answer is that for each domain, or even for each data structure, visualizing it well is itself a complex research problem.

by jasode 11y ago

Permit 11y ago

I actually wondered the same: Are these ideas meant to apply more broadly to programming in general, or are they a framework for learning? So I reached out to Bret on Twitter: https://twitter.com/ThisIsJoshVarty/status/631562151728025600 https://twitter.com/ThisIsJoshVarty/status/63156215172802560... (I see now he's deleted his Tweet...) In his response he told me to read the section "These are not training wheels" near the end of the blog. Here he says: >A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is a reasonable question, but it's somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. >Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming? I think the ideas he explores can apply more generally outside of creating environment for learning. And my understanding is that Bret believes they should apply to programming in general as well.

jasode 11y ago
>And my understanding is that Bret believes they should apply to programming in general as well. Yes I agree, but I think his 2D visualizations that you criticized were focused on "learning programming".[1] BV wasn't saying that extending it into "non-learning" scenarios for professional programmers must be a 2D feedback loop. Consider a new programming language with specialized syntax or a library of functions for moving a physical robot in 3D space. The feedback loop could be a live Bluetooth or wifi connection to a articulating robot arm on the programmer's desk. I wouldn't think BV would criticize that and say, "no, the robot arm must be 2d image on the screen". [1]key phrase of "presented in context for learning" from BV: "These design principles were presented in the context of systems for learning,"
- jules 11y ago
  The problem isn't things that we know how to visualize but do not fit the 2D model, the problem is the things that we do not know how to visualize well (which is most of the data in our programs). Visualizing the output of a program that does a 2D drawing is easy, because it's already visual. The hard part is doing it for general programming, and the essay is handwaving around that. I think the answer is that for each domain, or even for each data structure, visualizing it well is itself a complex research problem.