dont laugh

[Ian Hobson]

In article <G06pwL.DFF at world.std.com>, Will Ware <wware at world.std.com>
writes
>Jason Cunliffe (jasonic at nomadicsltd.com) wrote:
>> A lot of what mars many training video are basic film making mistakes:
>> lousy sound, poor focus...
>
>> I just finished watching ome video of a conference...
>> programmers navigating around their source files...
>
>This addresses my concern about video resolution. If source code is
>legible, that's the main thing.
>
>OK, I'm convinced, video is the way to go. Can you suggest any URLs
>about good video technique, and particularly getting good screenshots?
>
>As far as doing a good job of representing the Pythonic mindset, a
>couple possibilities come to mind. One would be to ask the expert to
Not so fast. 

Jason was right - it is the FIRST 2 hours that are vital, not the rest
of the course. 

Python MUST run "out of the box" (even on win32 - which it does not) and
then the ideas can be explained. 

I'm now past my first python prog. The MAJOR hurdles that I have crossed
include

a) Understanding that "Name error" meant I had forgotten an import line.

b) Understanding that syntax error meant I had missed a : 

c) Getting the resulting program to run from the start menu! 

I STILL do not know what the IDLE main screen is for - I have NOT used
it. 

And I'm not a newbie to programming - my first program compiled in 1966,
from paper tape! I have earned a good living at it since 1974. 


>construct good and bad examples, and explain what makes the good ones
>better. (In some cases, it might make sense to present a sequence of
>examples, going from horrible to adequate to elegant.)
>
>The other possibility is to record an instance where the expert is
>teaching somebody of lesser expertise. Hopefully the student will ask
>all the questions that the viewer would want to ask if he were there.

Regards

Ian

Ian Hobson 

Every time we teach a child something, we prevent him from inventing 
it himself. - Jean Piaget