On 20/06/2011, at 12:20 PM, Steve Dekorte wrote: > From this perspective we could see the history of programming as one of > finding ever more natural mappings between how our minds work and how we can > get machines to do what we want - just as steering wheel and floor pedals map > between our bodies and our vehicles. If so, which mappings are more natural > and under which circumstances seems to be the important question and one, > AFAICS, that may not well answered by simply replacing words with ideograms > and expressions with boxes and arrows.
Or even - might I proffer - that mapping are fairly arbitrary by their very nature, and therefore perhaps the mappings should be able to be inspected, translated between, and even completely reworked or added to as deemed fit. One of the issues that immediately springs from this is that as programmers of incredibly large (in terms of complexity) computers which don't offer physical switches, it's almost impossible to escape this abstract mapping, because the tools used to deal even directly with what makes up a computer involve a large amount of mapping (always at least two). It's not like we can switch switches anymore! In other words, the programming interfaces are virtual. We're always modelling. We need to also be CONTEXTUALLY EXPLAINING what the models are as we're modelling (ie baked into the modelling process, even) them so that people trying to understand the models (artefacts of our processes) can hold them in the right contextual frame. (Holding something in the right contextual frame is another name for understanding). What I'm stipulating, is not replacing words with ideograms and expressions with boxes and arrows, but building a representation (a visual mapping) such that it's immediately obvious what the intent of the "objects" in a system are doing. For example, if you have two numbers, then the numbers get visually transformed each to a set of dots with a perimeter (border) around them, and they're animated towards each other and the border becomes one border, and the dots all join into the one set... and then that set is animated into the sum of the two original numbers, this is *A* visual representation of addition. (note that there are definitely many others - there are many methods to doing something just as there are in other places in computing, and just as there are many styles to learning. If I didn't understand that representation of addition, then I pick another one, and interact with or watch that). Note that addition is a very low level concept used thousands of times a day in computer programming, so most likely most of *us* as fairly "complex" programmers wouldn't ever use this particular pedagogical tool... unless we wanted to explain addition to our kids... we might replace the "dots" with 3d oranges... and then a tiny child could understand the concept in seconds... Note also that the only thing I'm really interested in proposing here is that knowledge be inlined... that is... as I'm writing code, my intention is written down too... or to put another way... if I'm drawing a terrain map THAT I INCLUDE THE KEY FOR THE MAP WITH THE MAP ITSELF... so that later, someone can interpret what it means. This removes the need for documentation, and also allows it to be generated easily if it's required... but also, hopefully doesn't let people build things they don't understand... so that in the end if someone doesn't understand how something in particular works, well then the learning of it is in the environment where the object is itself... Note that this seems SO RIDICULOUSLY OBVIOUS to me that it's not even funny... it also makes explaining computer to people incredibly saddening, because to someone with the requisite knowledge, computing is incredibly easy, but getting the requisite bits of knowledge into the right parts of a person is often so frustrating for the person in question. One thing I liked about Self and to a lesser degree SmallTalk (especially Squeak) is that if you want to work out how something works, you yank it out, or build an example of it, and inspect it... and you can go on ad infinitum... inspecting... seeing how things are composed. There's still a HUGE amount of assumed and required knowledge in there in order to use the system, but the idea is what I mean... where there's a totally uniform interface that can be inspected to learn about it, up to the point that the original programmer decides to allow you to see inside it. I should be able to inspect to the degree of machine code... if I want to... to find out how my large sum addition is clothed in machine code on my particular computer... and perhaps even lower - see the particular way that byte-size integer addition happens on my particular machine if there's a pedagogical model in place to see it. I know for a fact that young inquisitive kids will find this fascinating, and when there's less stuff standing in the way of kids understanding (and adults! I want to learn this stuff, too!), we'll progress towards having what's deemed as really advanced becoming simply common knowledge, and this will be a good thing IMHO. Regards, Julian. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
