## Making computation concrete and easier to learn

I’ve mentioned before how much I enjoy the Computing At Schools online forum.  I got involved in a discussion about how to teach teachers programming, and the question was raised: Why do we have to teach programming?  Shouldn’t we just teach concepts? Neil Brown (in a blog post that I highly recommend reading) suggested, “We teach programming to make it concrete.”  One of the commenters suggested that memory is very concrete.  I disagreed, and am sharing here my response (for those who don’t yet belong to CAS), with editing and expansion:

Concreteness and abstraction in computing are difficult to define because, really, nothing in computing is concrete, in the Piagetian sense. Piaget talked about concreteness in terms of sensory input. I’ve heard before that “memory is concrete — it’s really there.” Can you see it? Can you touch it? Sure, you can “see” it in a debugger — but that’s seeing through a program. Maybe that memory is “made up” like any video game or movie special effect. It’s no more “real” than Yoda or Mario. We can sense the output of computation, which can then be Piagetian-concrete, but not the computation itself.

Uri Wilensky (who was a student of Seymour Papert) has a wonderful paper on concreteness. He redefines concreteness as being a quality of relationship. “The richer the set of representations of the object, the more ways we have of interacting with it, the more concrete it is for us.” Uri gives us a new way of measuring abstract-concrete in terms of a continuum.

• Memory is really pretty abstract for the novice. How many ways can a newcomer to computing view it, manipulate it? It might be really concrete if you know C, because you can manipulate memory in many ways in C. You can construct a relationship with it (to use Uri’s term). From Scratch or Python or Java, memory is totally abstract for the novice. There’s no way to directly manipulate it
• We did Media Computation because images and sounds are concrete. We get sensory input from them. So, computation to manipulate images and sounds gives us concrete ways to explore computation. We can’t see the computation, but as we change the computation and get a different sensory output, we can develop a relationship with computing.
• Threads are hopeless abstract. You have to be pretty expert, and know how to think about and manipulate processes-as-a-thing before threads can become concrete.

Entry filed under: Uncategorized. Tags: , , , , .

• 1. alanone1  |  July 2, 2013 at 5:16 am

Yet another comment along the same lines …

An important confusion and thus even more important distinction is between “gears” and “mechanism”.

For example, suppose we want to make a process that will give us an accurate time of day.

If we are thinking “gears” we will try to organize and mesh them to create a “clockwork” that can measure out time for us.

On the other hand, if we are thinking “mechanism” we will look widely at many kinds of materials and processes that might be employed to gain our end.

In this day and age, we’d find much more accurate and less expensive means for telling time than those that require gears.

Computing is a bigger idea than “recipes for progressive actions on ‘data’ ” — whether the data is supposed to represent “sounds” or a “program”.

Educators have consistently mistaken and confounded “today’s practices” — many to most of which are at best weak and more often plain bad — with what “Computing” is all about. This is not an exclusive complaint about educators, because most of the field itself also is trapped by this deadly embrace.

The insistence on “gears” because “we have always had gears” and “most of the human made mechanical processes today uses gears”, enforced in schooling simply holds back progress and creates more semi-practitioners with weak views.

And — to the point of a recent blog post — the first thing that really has to be done is to formulate a picture of “real computing” that gets at what is actually fundamental about it — hint: it’s not “gears”.

Then it will be possible to come up with what parts of this children and teachers need to learn, and ways for them to learn it.

The current approach of “gears first” misses the point, and undermines attempts at progress.

• 2. Mark Guzdial  |  July 2, 2013 at 8:34 am

Alan, in Seymour Papert’s essay, “Gears of my Childhood,” he argues for the value of gears as a way to get to mechanism. Gears for him served as a motivation to dig deeper into mathematics. Are you disagreeing with Seymour about the value of gears, or are you suggesting that Seymour and everyone else would go further if they didn’t start with gears?

Epistemological Pluralism and the Revaluation of the Concrete” by Seymour and Sherry Turkle is one of my favorite papers in this space. They argue for the value of using the concrete to get to the abstract. Not everyone does, they point out. But starting from the concrete (the “bricoleurs”) is just as valid as valuing the abstract more (the “planners”), in their argument.

Cheers,
Mark

• 3. alanone1  |  July 2, 2013 at 9:12 am

Some children will find tinker toys to be a better starting place than gears for mechanism. This is why Seymour put so much work into the precursors of Lego Mindstorms to show many kinds of mechanisms and the general idea of analysis and synthesis of systems made from parts.

Seymour and I had many discussions about the pluses and minuses of bricolage. We agreed on the pluses — bricolage is built not just into us and most primates, but many mammals. The problem with naive bricolage is that most humans — for the very same biological reasons — are happy to stay with tinkering (and historically did for thousands of years).

To me, this is one of the biggest problems in computing today — the nature of the “materials” allows much worse kludges than can be put together in the physical world.

The conflict here is not between the concrete and the abstract — at least not for me: I think starting with the concrete is important for almost every one.

The conflict is not even about “which concretions?” but “which concrete relationships?”. Or perhaps “which *profound* relationships?”

This is why I was so taken with Ivan Sutherland’s “Sketchpad” when I saw it — it exhibited a more profound version of computing than the computer it ran on, and yet its exhibition was also more concrete.

A few years later when I met Seymour and saw what he was doing — just wonderful insights! — it was combining those with the simulations of systems that is what is profound about computing that seemed like a great path to follow for children.

This is not so much adding something abstract, but adding *context*. In this view, the “Mathland” one goes to has many interesting things in its environment — it’s a whole world — it is not just a single path of artifacts made with a weak part of math.

To take an example from your own history — when you used to teach MediaComp using Smalltalk, pretty early on you would use the fact that Smalltalk is its own OS and environment to just draw a line across the screen or erase part of a window that up to then to most users seemed to be part of the intrinsic hardware. It was a big moment for students to realize that everything they were doing was made out of the same stuff, and they could get to it.

This is real concretism — and in the context of the bigger systems ideas.

“Misplaced concretism” via naive bricolage has produced a field that in so many ways has lost its way in what computing is actually about, especially a computing that has embodied Moore’s Law for the last 50 years.

• 4. Fred Martin (@fgmart)  |  July 2, 2013 at 6:57 pm

Things are pretty abstract now, and they used to be more concrete:

* My first computer was a TRS-80. It had 1K of memory that was the video buffer (16 rows x 64 columns). You could just write stuff into that memory and it showed up on the screen.

Even at the BASIC interpreter, you could use the POKE command to get a char to appear immediately.

I filled it with random numbers and then wrote an assembly lang bubble sort on the 1K of data. That was fun.

* In the 1980s LEGO/Logo, you’d type “ONFOR 20” into the command center, and the motor would turn on for two seconds.

There are so many layers of abstraction now. I think it makes it harder to understand what’s really happening.

I recently discovered du Boulay’s ideas about the notional machine. It’s a good exercise to be explicit about what we’re saying is going on.

It’s a lot easier to do this when the notional machine and physical machine aren’t so far apart…

Fred

• 5. chaikens  |  July 3, 2013 at 5:26 pm

“Why do we have to teach programming? Shouldn’t we just …?” could only have been asked by a teacher who has not yet been successfully taught programming. I think that the best response is to say programming is like writing, art and swimming. I’d say math too, but too many teachers don’t know math either.

This site uses Akismet to reduce spam. Learn how your comment data is processed.