I agree, even with your depiction of the tension between law/power and approachability. My "monoid" example was just that, an example. The notion of structure (as in "group", "ring" or "monoid") is certainly much more important, and perhaps there's more fundamental concepts.
Maybe category theory should be taught in kindergarten. (This is not a joke: we human are atrociously bad a manipulating abstract concepts, but maybe a good subset of children could grow to adapt to it?) As for a practical answer to the problem, we probably need to do more research. And then adapt the institutions accordingly (knowing how to do _that_ may need yet more research). (By the way, I just came back from LessWrong, and right now I'm scared. We can end the world, but we don't know how to secure it. Our children may find a way, but I would be much reassured if we could raise a generation of kind people who can nevertheless follow the cold hard calculations when lives are at stake. The VPRI's research may be much more urgent than we think.) Loup. David Barbour a écrit :
I agree there's much value in lawful, powerful building blocks. I would formalize that with composition law (i.e. exists F. forall X,*,Y. P(X*Y) = F(P(X),'*',P(Y)), for some useful set of properties P). We can find many lawful, powerful building blocks in category theory or algebraic topology. Basically, with 'lawful' and 'powerful' you're saying that there isn't much point to starting concrete if it will limit us later. But that leaves "approachable" as a problem. I think most concepts - even arrows or monads - can be made approachable after working with using concrete examples (that are individually useful) and gaining some intuition for the composition laws. I.e. start concrete and work towards abstract. If you start by tossing concepts like 'arrows' at students, they'll be quite intimidated. If a language requires users `import Control.Arrow` or `import Control.Monad` before they can use concrete instances, it is not helping with the learning process. On Mon, Dec 3, 2012 at 4:22 AM, Loup Vaillant <[email protected] <mailto:[email protected]>> wrote: David Barbour a écrit : On Sun, Dec 2, 2012 at 6:12 AM, Pascal J. Bourguignon <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>__> wrote: Julian Leviston <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> writes: > Concrete is better than abstract for learning. Definitely. Programmer students should learn assembler and write a couple of assembler programs. Concrete doesn't mean "low level". It means "not abstract". A spreadsheet, for example, is concrete and high level. Logo Writer is concrete and high level. Wire diagrams are often concrete and high level. I think student programmers are well served starting concrete and high level. I'm not sure we can pin down what students need with those terms. Most of the time, "concrete" actually means "familiar". Something concrete is something you can touch, feel, understand at a glance, or otherwise relate to. Compare for instance: x = y - z price = cash - reminder The second line is arguably more concrete than the first, despite having exactly the same structure, because we can relate to prices and cash better than to letters in the void. Spreadsheets are concrete because they provide immediate feedback. Logo Writer is concrete because it provides *simple* feedback: the Turtle can only lower the pen and leave a trail, and its internal state is both very small and easy to relate to (location + direction)). Wire diagrams are concrete because they often represent wires you can solder in the obvious way. Sometimes however, this "concrete" thing is directly at odds with the need to learn good programming. Take for instance the concept of monoid. Very simple (a set, a binary op, and 2 rules: associativity, and the existence of a neutral element), yet extremely useful: loads of useful idioms use monoids, and much code can be factored out if only the programmer was monoid aware. On the other hand, the general concept of "monoid" is quite abstract. There is no escaping letters in the void, especially if you want your students to see monoids in things as diverse as numbers, lists, and side effects (I have seen a study where teaching the abstract concept before teaching concrete instantiation helped the students when they had to tell whether some new instantiation matched the concept). My current guess is, more than concrete things, students need approachable, lawful, powerful building blocks. - Approachable: I mean easy to use by a typical CS student. The '+' operator, for instance is highly familiar, and therefore easy to use. Logic gates can be made approachable if their study is coupled with a little wiring of actual logic gates. - Lawful: the rules that the building blocks follow should be simple, with as few special cases as possible (they seem less arbitrary that way). The amount of magic under the hood is less important, as long as it does not shows through. - Powerful: The student must feel those building blocks can make "real programs", and such must require relatively little code. I was taught Ocaml in my first year at college. It would have been much better if they didn't try to explain how "environments" implement lexical scoping (at least not before we were shown side effects), and if they showed we could make real programs on the command line, instead of trapping us in the REPL. Loup. _________________________________________________ fonc mailing list [email protected] <mailto:[email protected]> http://vpri.org/mailman/__listinfo/fonc <http://vpri.org/mailman/listinfo/fonc> -- bringing s-words to a pen fight _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
