On Tuesday 31 July 2001 20:04, Roger Kenyon wrote:
> Doesn't it seem that the typical introduction for the non-programmer
> is bass-ackwards. After an overview, there may be a tutorial and
> reference section. Along the way, it introduces objects, messages,
> controls, classes, methods, inheritance, and so on.

I have met many people who have taken "computer course" and yet failed 
to become programmers. Language details are important, of course, but 
they are not the main thing that programmers know and non programmers 
don't. Here is what I wrote a long time ago about which ideas need to 
be taught:

  http://www.lsi.usp.br/~jecel/tut1.html

I would combine the ideas of "generalization" and "factoring" into a 
single "making things smaller". And it would be better to use something 
like the "spiral pattern" (see "whole course concerns" in 
http://www-lifia.info.unlp.edu.ar/ppp/element.htm) than to have 
separate modules as suggested in my page.

Speaking of patterns, I would say that Design Patterns have done a 
wonderful job of identifying things a programmer should know.

> Case in point: http://www.inf.ufsc.br/poo/smalltalk/vwin20/index.htm.
> As a traditional intro, its pretty good, but it is not for the
> non-programmer.

The net isn't working too well for me today (I got the top page, but 
not the frame contents yet) but I'll take your word for it. Too bad the 
Federal University of Santa Catarina is less Smalltalk oriented these 
days (I am sure there are people on this list who don't agree, but I am 
thinking of those not on the list who have switched to Java) and the 
group at UFPE seems to have switched completely.

> Let's try another poetry class. We learn how to write descriptively
> so the reader envisions a mind movie; being transported in imagery.
> We learn how to write emotively through cultural-linguistic symbols.
> We learn how to write so the words themselves are part of the
> message; and so on. Each time checking, if we do this, then that
> happens. Likely result, we approach poetry as an activity; language
> as a vehicle; sympathy as a destination.

And in the case of a regular class setting, you can get good results by 
having people read poems out loud to each other. The sounds themselves 
are important and just imagining them on your own isn't the same thing.

> So how does one create a first-person approach applicable to learning
> Squeak? The folks at StageCast have a tutorial  for Creator that
> combines traditional "introduction to the elements" with a guided,
> hand-on approach. That's closer, but not yet there.

In my "book vs interactive adventure game tutorial" problem, I would 
say that it is harder to do a hands-on course with a book.

> This is exactly what I am getting at in the Morphic Modeling in
> Middle-School Mathematics [MMMM] project (hey, sorry about not
> putting the outline in .zip or .sit format ). Squeak is a medium for
> dynamic what-if modeling. It is digital play-doh, pixel plasticine,
> and as such is effective for (2D, 3D, musical, . . .) cause-effect
> investigations.
>
> What does this suggest as an intro for the non-programmer?

It does suggest that a simple text won't do a very good job, first of 
all. You will waste three pages just describing how to use the menus or 
the flaps to start a new painting.

Some of the squeakland projects are already good examples of the 
direction to take. The problem is that if you give the student too much 
control it is impossible for an automated tutor to keep up. Specially 
since things break so easily.

The other extreme is the book, with nearly 100% author control. Or the 
movie. Much better for showing off Squeak. This could reach out to even 
more people than bookstore customers if it were shown on TV. That was 
the idea behind the original BBC Basic course (for which Sinclair and 
Acorn designed very neat machines), right? I didn't see it and have no 
idea of what the results were. And today you can distribute a movie on 
tape or a CD-ROM (or DVD), including in a bookstore.

This reminds me of the really nice "Self Movie". It is very well done 
and I have shown it to several non programmers to see their reaction. 
It starts out very well but Randy Smith loses his audience with his 
quick explanation of method execution as cloned prototype context 
objects (got that? ;-). People then ignore everything he says until he 
starts demonstrating how to take things apart in Morphic.

Are there any artists in the house? ;-)
-- Jecel