My son wants me to teach him Python

[Rick Johnson]

On Wednesday, June 12, 2013 2:46:13 PM UTC-5, John Ladasky wrote:
> [...]
> He's a smart kid, but prefers to be shown, to be tutored,
> rather than having the patience to sit down and RTFM.
> Have any of you been down this road before?  I would
> appreciate it if you would share your experiences, or
> provide resource material.

Hello John. 

I'm going to suggest a completely different path to enlightenment for the lad. A path that has the potential for semi-instant gratification whilst also humbling the boy to the grim realities of computer graphics and application development. *evil grin*

Since your son has zero experience with both graphical and application based programming i would suggest starting at (near) the very bottom of the GUI spectrum, which, in the Python world would be the Tkinter Canvas. 

Some people would suggest starting with "turtle.py", and yes this is a good suggestion, however, i highly suggest that he begin by coding a python turtle program HIMSELF. 

But first i would let him use the existing turtle program, play around with it, understand some of the commands, etc... but whatever you do: DON'T LET HIM SEE THE SOURCE CODE! Then i would ask him to think about how this program works in a general manner (psst: remember, he's not a programmer "yet"!). 

For starters we know we need to create a "window" (this is where you would explain what a GUI library is. And to satisfy the instant gratification, we should create a window very soon. 

After we can create a blank window, we should take this opportunity to quickly cover some of the common subwidgets that can be placed into a window, such as:: "Text", "Entry", "Label", "Button", etc.., and maybe some simple code to display each of them will be fun.

Now that we know "generally" what a GUI is, and we know about windows and sub-widgets, it's time to refocus on the turtle program. We will need to create a drawing area within the window for which to draw the turtle -- enter the Tk::Canvas!

Next we can take a slight tangential meandering and learn about common Canvas primitives (like rectangles and lines and whatever!) Then we should decide which primitive would best suit a turtle, and draw that primitive.

Once we have drawn the turtle, we quickly realize that it needs to sprout some legs and move around. This is where the fun really starts to begin... I think you can figure out where to go from there. Math functions, event processing... fun times!

After he gets a simple turtle program running i would point out that even though he went to quite bit of work to solve this fairly simple problem, most of the really difficult code, like turning pixels on and off, drawing and ordering GUI windows, event loops, etc, etc...  has been abstracted away into multiple layers of low level code. Even though the starting point of our project could be considered "slightly low level" relative to Python, there are vast libraries of millions of lines of code, layered one atop the other, making all this possible.

The point of this exercise would be to get him thinking about solving problems instead of just reaching for a prepackaged library, and then not fully appreciating (or furthermore, truly *understanding*) the vast scope of *real* software design. 

Anybody can grab PyGame and start making simple games, but do they understand what is going on under the hood? I don't think they need to understand the science behind the internal combustion engine, however, if they cannot explain the basics of how the major components like: electrical, fuel, suspension, drive-train, braking, etc... work, then they lack a fundamental insight into solving complex problems that can arise later. 

For instance, if you hear a knocking sound whilst driving but the sound is absent whist idling, you can deduce that the problem most likely exists in the drive-train. From there you'd need to focus in at an even smaller level of detail -- but you could not come to that conclusion if you did not possess (at minimum) a basic understanding of the underlying component systems. 

Of course some might say:  "Rick, why go to all that trouble when you could traumatize him with openGL instead". And to that i would reply: "Save OpenGL for lesson number two!" 

*wink*