This was a very interesting and inspiring talk. It makes me wonder what we can do to make building larger software systems better, which don’t necessarily have a GUI component. When building distributed systems, sure, you can gather metrics and logs and discover what’s going on after the fact, but is there a way to instrument better during the development stage, in the same way that Swift, or Lighttable, or Mr. Victor’s other experiments allow seeing into games and interactive applications?
It’s interesting that he doesn’t mention “hackerspaces” at all by name in a talk that’s entirely about making “makerspaces” better for hacking by giving them, you might say, debugging tools.
While I agree in spirit, it would have confused the conference attendees at bit with jargon, the word hacker has replaced inventor in the code-scene, it still doesn’t have a clear connotation. The viewers have a good mental model of the process of invention and not with debugging as related to computers. His talk struck me more as a laboratory that perceives, where one could augment time and space in a qualitative way with quantitative information. Debuggers in the specific sense allow one to stop local universe from advancing to the next state, they offer very little in the overall perception of the running program. I would love to see people start to explore new ways of seeing and experiencing program execution. Print statements are nice, but debuggers and tools that operate in the execution domain can offer amazing insights.
What Bret Victor offers is an externalization of our mind into perceptualizing causal relationships by lifting the feedback loop from a low bit-rate quantitative regime to high bit-rate qualitative one.
I think DDD has offered the ability to graph arbitrary expressions over time for many years. It seems like something I’d be interested in using, but for some reason I never use it.
My point about “hacker” is that hacking embraces both inventing and understanding, both engineering and science. And Bret is talking about making “makerspaces” embrace both inventing and understanding, rather than having them be limited only to inventing. So it surprised me that he didn’t even think to mention “hackerspaces” in the talk, since that’s perhaps the more common name for “makerspaces”, and certainly the older one.
To address your DDD comment, I know that in the past I haven’t taken the time to learn debugging tools in a non stress scenario. Whenever I have used a debugger, it was because I need to solve a problem right now, which never really translates well into a deep learning. I did do this with pdb and it has definitely paid off over the years. I never did this with gdb and lldb until recently. I am not sure what to do about it, take more time to solve problems? Try and understand the root causes more fully and prevent the meta problem in the future?
In my early years I fixed too many bugs by side effect and not by first principles, that has now changed.
This was a very interesting and inspiring talk. It makes me wonder what we can do to make building larger software systems better, which don’t necessarily have a GUI component. When building distributed systems, sure, you can gather metrics and logs and discover what’s going on after the fact, but is there a way to instrument better during the development stage, in the same way that Swift, or Lighttable, or Mr. Victor’s other experiments allow seeing into games and interactive applications?
It’s interesting that he doesn’t mention “hackerspaces” at all by name in a talk that’s entirely about making “makerspaces” better for hacking by giving them, you might say, debugging tools.
While I agree in spirit, it would have confused the conference attendees at bit with jargon, the word hacker has replaced inventor in the code-scene, it still doesn’t have a clear connotation. The viewers have a good mental model of the process of invention and not with debugging as related to computers. His talk struck me more as a laboratory that perceives, where one could augment time and space in a qualitative way with quantitative information. Debuggers in the specific sense allow one to stop local universe from advancing to the next state, they offer very little in the overall perception of the running program. I would love to see people start to explore new ways of seeing and experiencing program execution. Print statements are nice, but debuggers and tools that operate in the execution domain can offer amazing insights.
What Bret Victor offers is an externalization of our mind into perceptualizing causal relationships by lifting the feedback loop from a low bit-rate quantitative regime to high bit-rate qualitative one.
I agree.
I think DDD has offered the ability to graph arbitrary expressions over time for many years. It seems like something I’d be interested in using, but for some reason I never use it.
My point about “hacker” is that hacking embraces both inventing and understanding, both engineering and science. And Bret is talking about making “makerspaces” embrace both inventing and understanding, rather than having them be limited only to inventing. So it surprised me that he didn’t even think to mention “hackerspaces” in the talk, since that’s perhaps the more common name for “makerspaces”, and certainly the older one.
To address your DDD comment, I know that in the past I haven’t taken the time to learn debugging tools in a non stress scenario. Whenever I have used a debugger, it was because I need to solve a problem right now, which never really translates well into a deep learning. I did do this with
pdband it has definitely paid off over the years. I never did this withgdbandlldbuntil recently. I am not sure what to do about it, take more time to solve problems? Try and understand the root causes more fully and prevent the meta problem in the future?In my early years I fixed too many bugs by side effect and not by first principles, that has now changed.