I remember reading this back in 2011 and thought it presented some amazing ideas. Later I've studied physics with focus on simulations (mechanical systems, spring models, gases and so forth) and I'll have to admit that I haven't been able to apply it in practice.
Yes, it's always cool to have multiple visualizations of the same concept at different levels of abstraction, but in real-life there's always a trade-off between how much time you invest in visualizations and what you actually learn from it.
In this example I would say that the real-time simulation doesn't actually teach me a lot. It behaves exactly how I would suspect from reading the algorithm the first time. Being able to control the time and the angle is cool, but I need to interact a lot with the visualization to learn anything. It's also hard to actually compare different angles.
In comparison, with just a simple plotting tool I can easily create two graphs:
- For a specific angle, let X-axis be time and Y-axis be the displacement from the center.
- Let X-axis be angle and Y-axis be mean (or max) of the displacement for the whole period.
The first one will give me some intuition about how the system behaves, and the second one will immediately show me that it's impossible to find an angle which gives a good result — which suggests that the algorithm in itself isn't good enough.
I totally see that the tooling created in this neat, but how much more to learn from these tool over the two mentioned plots? And how long did it take to create these tool? That is for me the biggest question.
Example:
> We want direct, interactive control of each parameter, so we can go forward and backward, stop, and jump to arbitrary positions. This allows us to travel freely around the territory, investigate areas of interest, and pose and verify hypotheses as quickly we think of them.
In my physics simulation I've rarely needed a tool at this fidelity. Looking at a single use case just doesn't give me enough information and dragging sliders is very time consuming. I've pretty much always ended up defining a metric (which is mentioned in the article) and plotting that for various parameters. It's amazing how much you can learn about a system with such a simple visualization.
Yes, currently trying to create these tools by hand on a case by case basis is awful, however I think the point of Bret Victor's work is to imagine a world where this type of tools come by default (or are easily created) with every programming environment.
I think this is something that would be immensely useful. But I don't know how to bring this vision to reality.
I found the army to be a very good example to explain abstraction layers. It's intuitive, that a general should not know about the flawed boot of a soldier. It's also intuitive why the rarer it is used every day the more it is factored out into specialized services.
the procedural nature of beginner programs is like a obsessive drill seargant.
Its even nice for a start into parallelism.
>>It's intuitive, that a general should not know about the flawed boot of a soldier.
Yes the army is a good example, with the caveat that if too many soldiers have flawed boots, i.e., there is a problem in the supply chain that results in many flawed boots, and this results in many soldiers who appear ready but are actually not ready for battle, the general better damn well know about this flaw.
As the saying goes: 'privates think about techniques, sergeants think about tactics, lieutenants think about strategy, and generals think about logistics'.
So the article is right that the key is to be able to run up and down the chain of abstraction as necessary, usually filtering out the details, but raising prominence of key details that will affect system performance or that can cause unexpected failures.
Yes, it's always cool to have multiple visualizations of the same concept at different levels of abstraction, but in real-life there's always a trade-off between how much time you invest in visualizations and what you actually learn from it.
In this example I would say that the real-time simulation doesn't actually teach me a lot. It behaves exactly how I would suspect from reading the algorithm the first time. Being able to control the time and the angle is cool, but I need to interact a lot with the visualization to learn anything. It's also hard to actually compare different angles.
In comparison, with just a simple plotting tool I can easily create two graphs:
- For a specific angle, let X-axis be time and Y-axis be the displacement from the center.
- Let X-axis be angle and Y-axis be mean (or max) of the displacement for the whole period.
The first one will give me some intuition about how the system behaves, and the second one will immediately show me that it's impossible to find an angle which gives a good result — which suggests that the algorithm in itself isn't good enough.
I totally see that the tooling created in this neat, but how much more to learn from these tool over the two mentioned plots? And how long did it take to create these tool? That is for me the biggest question.
Example:
> We want direct, interactive control of each parameter, so we can go forward and backward, stop, and jump to arbitrary positions. This allows us to travel freely around the territory, investigate areas of interest, and pose and verify hypotheses as quickly we think of them.
In my physics simulation I've rarely needed a tool at this fidelity. Looking at a single use case just doesn't give me enough information and dragging sliders is very time consuming. I've pretty much always ended up defining a metric (which is mentioned in the article) and plotting that for various parameters. It's amazing how much you can learn about a system with such a simple visualization.