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/

[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