On Thu, Sep 27, 2012 at 9:31 PM, Stephen Jacobs <[email protected]> wrote: > Originally brought to my attention via the Sugar Labs/OLPC IAEP mailing list > > http://worrydream.com/LearnableProgramming/
Argh, you beat me to it ;-P It was a great article. i was a bit bothered by the "copy and paste" code composability example. Maximal composability is good, but sometimes you really do have state or context. "fill" is a bad example because it's a silly interface. Languages have different ways of dealing with state, such as making it temporary within a scope or "undo-able" (via dynamic binding). Getting rid of it altogether (by passing it in as a parameter) can help, but sometimes it increases cognitive load (because now there's this extra argument that i have to pass into the next N function calls). A thing that i like about visualizing program output is that it ties back to the early days of computing, or even before. People like Gauss (a human "computer" as well as a mathematician, which was unusual in those days) and Wilkinson (worked with Turing; a father of numerical linear algebra) always used to watch the intermediate output of an unfolding computation. They had a sense for when it was going wrong, and for the algorithmic choices that would more easily tolerate "temporary wrong-ness" due to rounding error or even human error (Gauss favored "self-correcting" iterations). i work on algorithms that can tolerate data corruption or incorrect arithmetic; it would have helped me a lot had i had a stronger sense for "right-looking" intermediate output of algorithms. mfh _______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
