I've always visualized what's going on, this is how I do everything. Doesn't everyone program this way? Think about something for a while, building up the model in your head, then visualize the interactions among the parts. If the problem is too complex to visualize, then I simplify and add abstractions until I can visualize it. This iteration naturally creates simplified abstract layers in my code.
I debug most of my code this way also. When I'm internally visualizing stuff, I lose track of what's going o
I'm not affiliated with the author in any way, but I did buy the book (though you can get it for free).
This is an amazing resource for someone new to D3.js [d3js.org]'s declarative javascript and helps you put it all together: https://leanpub.com/D3-Tips-an... [leanpub.com]
After using D3.js, I've come to the conclusion Mike Bostock is awesome! But it doesn't stop there, people have expanded it like Crossfilter [github.io] and dc.js [github.io].
Tech that allows a javascript n00b like myself to build a simple race results visualization [nullchar.net].
Actually, after reading the article, I'd call what he's doing extremely good basic engineering and model design/view. It's very cool for the problems he presents, but looks like a ton of work. To be generally useful, it seems he'd have to come up with rules of thumb and generalizations for what it is typically important to see/understand in a given algorithm and a way to identify *what* to model/visualize that isn't completely subjective.
He appears to make some great subjective decisions on what/how to do
I debug most of my code this way also. When I'm internally visualizing stuff, I lose track of what's going o
I'm not affiliated with the author in any way, but I did buy the book (though you can get it for free).
This is an amazing resource for someone new to D3.js [d3js.org]'s declarative javascript and helps you put it all together: https://leanpub.com/D3-Tips-an... [leanpub.com]
After using D3.js, I've come to the conclusion Mike Bostock is awesome! But it doesn't stop there, people have expanded it like Crossfilter [github.io] and dc.js [github.io].
Tech that allows a javascript n00b like myself to build a simple race results visualization [nullchar.net].
Actually, after reading the article, I'd call what he's doing extremely good basic engineering and model design/view. It's very cool for the problems he presents, but looks like a ton of work. To be generally useful, it seems he'd have to come up with rules of thumb and generalizations for what it is typically important to see/understand in a given algorithm and a way to identify *what* to model/visualize that isn't completely subjective.
He appears to make some great subjective decisions on what/how to do
This is total nonsense.
Algorithms are first _designed_ BY humans. Algorithms can be _optimized_ FOR computers.
Visualization is a way to augment understanding, not replace it.
There are 4 primary ways of learning:
* visual,
* auditory,
* kinesthetic, and
* mental.
Students have various ways that work "best" FOR THEM. Saying visualization is dangerous shows your ignorance about the subject. If you had seen the excellent move Temple Grandin you would understand that not everyone thinks the same way. [imdb.com]