Yes. A concrete way to teach an abstraction is to provide multiple concrete examples each of which are different excepting their abstract commonality.
For example, addition is an abstract concept when compared to the concept of identity. It is known that one way of teaching it is by grouping identities (objects) of one type and then showing a similar grouping of objects of another type. Pigs, ducks, oranges, computers. Once you've shown a few examples of this, it becomes obvious. By saying "Concrete is better than abstract for learning", I'm not in any way discounting previously understood concepts, quite the opposite. For example, multiplication can be taught without reference to addition. What a pain! In my opinion, understanding is the process of concretising knowledge into being... that is, when I understand something, I literally include that knowledge into my self. You've no doubt experienced this process. That's why the word understanding is such a fascinating word to me. You put your body under the knowledge. If one understands addition thoroughly, one can be taught multiplication more easily than if one doesn't understand addition... because one has less of an abstract leap to make... perhaps by someone saying to you "one way of looking at multiplication is that it is adding or counting groups each with the same numbers of things in them", and then showing how the concept of 4 groups each with 3 chickens in them can be "speed counted" with multiplication by taking each group of three chickens and adding them together, OR by taking one group of three chickens and counting them four times, etc.... then taking this and trying with different groups of different things. Note that I chose a "simple" example so that you'd understand. Some might say I chose a fairly concrete example, however there were no actual chickens or oranges, or any of the objects I referred to involved. We use abstraction so much in our lives, and quite a lot of us don't understand it very well, that it's often hard for us to know what is abstract and what isn't. I have no doubt that's why advertising "works" so well on us (often causing most people to buy things they don't really necessarily want or need). I would say that the concept of addition is so well understood by us all that it *is* concrete for us, in terms of understanding. Thus, what is concrete for me may not be concrete for you. What is solid is what I understand fully, and what is not so solid is the body of knowledge that I do not yet understand. My point is simply that if you want someone to learn, you should use objects that are concrete to the person, and yes they can be very abstract objects in terms of general understanding. I am sorry I generalised to such a degree that may have left you all misunderstanding me. I think and hope the idea of scale makes more obvious that which I was attempting to communicate. I think addition is a very abstract concept in terms of uneducated people and very small children, but for us, it's completely concretised. Things that are basic for you, or not basic for me, and vice versa. Much Love, Julian On 04/12/2012, at 3:07 AM, David Barbour <[email protected]> wrote: > 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 > > > > -- > 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
