4 ms·
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
by 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 agoThe 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.