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]> wrote: > David Barbour a écrit : > >> On Sun, Dec 2, 2012 at 6:12 AM, Pascal J. Bourguignon >> <[email protected] <mailto:[email protected]>**> wrote: >> >> Julian Leviston <[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] > 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
