Outline for Teaching Programming to kids

[DavidS]

Sorry about the title beig incomplete I did not want it to be to long.

I am aware that there are many views on the best way to teach young people to program. I think that one of the big misconceptions is the idea that they can not understand it until age X. Remember that it is no more dificult to teach a child than teaching them how to read (and a lot easier than teaching an english speaking child to read english [we have a complicated language, with many rule exceptions]). So herin is my view:

The outline for teaching young people to program that I propose is:
1 FIRST: Begin by teaching kids that you can do interesting things with a computer, using something simular to LOGO. Begin with something akin to turtle graphics, then on to very simple procedure grouping akin to "ON something DO" in LOGO. This is greate for kindergarden and first grade.
2 SECOND: Teach them a good simple structured procedural language such as PASCAL with support for modules (Standard Pascal does not have this) or some other procedural language that is not OO. Give them a good feel for declaring everything and structured procedural programming. This should not take more than one semester.
3 THIRD: Start to teach them modular programming, using the same language used for step 2.
4 FOURTH : Get them into structures. This is the bases of OO, though not yet including methods.
5 FIFTH: Get them understanding memory addressing and pointers (a core concept for how OO works).
6 SIXTH: Teach some OO. Get them into using objects.
7 SEVENTH: Teach them to create objects, use inheretence, etc.
8 EIGHTH: Teach them how OO works. Show them how an object is nothing more than a structure containing the data elements of an object, and that a method is nothing more than a standard procedure that takes a pointer to the current instance of the object as one of its arguments, that is normally hidden (in many languages refferenced as this).

By this time they will be in the 5th or 6th year of school (Grade in the US), and ready for more formal CS education in intermediate and secondary (high) schools, for those that continue with that path. Then once they reach university they will have a good background and be able to continue with CS with little difficulty, if they so choose.

Also do remember to teach them good habits to commenting code. This should be an implicite statement though just in case I am explicitely stating it.

[Spid]

http://www.raspberrypi.org/archives/2965

[DavidS]

http://www.raspberrypi.org/archives/2965

VERY YOUNG KIDS, and PROGRAMMING.

[tufty]

David, whilst I can't argue with the idea of using multiple languages to bring across concepts, you appear to have a very profound misunderstanding of what Object Orientation is and isn't.

[gritz]

My methodology (triviality alert)

1) Teach an appreciation of the beauty, simplicity and truth of science and how it meshes with people, both as individuals and within groups. Everything else will follow.

2) Find the idiot that coined the phrase "Object Oriented Programming" and beat the soles of their feet until they agree to give it a better moniker. Something like "recycle, re-use" springs to mind.

3) Ban beards.

That's about it, really.

[DavidS]

David, whilst I can't argue with the idea of using multiple languages to bring across concepts, you appear to have a very profound misunderstanding of what Object Orientation is and isn't.

I know what OO is suposed to be. Though what it actually is in most cases, is what I was pointing to above.

[tufty]

In which case, teach what it's supposed to be, rather than geting hung up on implementation details of a specific form of OO in certain types of languages.

Programming, once you get past the actual syntax of a particular language, is about abstractions, not mechanics. There's far more ways of abstracting OO than just the class-method-inherit model, and far more, in many cases more useful, abstractions than just OO.

Anyone can learn the syntax of a language or languages, the core of programming is learning how to apply abstractions to the problem domain.

[jamesh]

http://www.raspberrypi.org/archives/2965

VERY YOUNG KIDS, and PROGRAMMING.

Scratch.

There doesn't appear to be a decent alternative to to it. Needs to be graphical - young children cannot type or perhaps even spell, but are deft with a mouse! Instant gratification also helps - you do something and something happen immediately.

[DavidS]

In which case, teach what it's supposed to be, rather than geting hung up on implementation details of a specific form of OO in certain types of languages.

Programming, once you get past the actual syntax of a particular language, is about abstractions, not mechanics. There's far more ways of abstracting OO than just the class-method-inherit model, and far more, in many cases more useful, abstractions than just OO.

Anyone can learn the syntax of a language or languages, the core of programming is learning how to apply abstractions to the problem domain.

Ok point taken. This is just an outline, can be changed (even though this board will not let me edit my initial post [only board I have ever used with this limit, (even the old WildCat 5 Hosted boards allow editing old posts as long as they are yours)]).

[DavidS]

http://www.raspberrypi.org/archives/2965

VERY YOUNG KIDS, and PROGRAMMING.

Scratch.

There doesn't appear to be a decent alternative to to it. Needs to be graphical - young children cannot type or perhaps even spell, but are deft with a mouse! Instant gratification also helps - you do something and something happen immediately.

Yes Yes, this could be in the catagry of LOGO or "simular". I was attempting to point to something that meets the needs of keeping very young kids attention (though I whas thinking 4 to 6 year olds which should know how to type a little [of cource this does depend on what level of education there parents provide them]). But Yes scratch is a good Lanuage to stat them and at least get them interesed and keep there attention.

[dextrus]

I've tried all this, and it doesn't work unless the student (or kid) is already inclined, IMHO.

It's a very, very complex subject, but in a nutshell my approach is: make your students design and build a game they want to make. Twice. They will almost certainly fail in both cases, but will then have learned a lot. It's a hard way to teach though. Be warned. Don't confuse this with the oft maligned "Problem-Based-Learning" approach, because it's not as prescribed as the text-books say, and you will have more trouble given the nature of the project (i.e. games. Artists versus programmers versus designers versus project mangers (And you get this distinction in 4-6 year olds)).

After that (I've tried this for 8 years now), they will choose the language appropriate for them. Most adult students are veering towards Unity at the moment (a game-making package that supports C#, java and if you pay, C++), but they all appreciate C and C++ in the end. C#, Lua, Python and Javascript shouldn't be dismissed. Let them choose. As an educator, you are already behind the curve when it comes to programming in the Creative Technologies sector anyway.

That being said, I did get my employer to pay for me to go to the Game Developers Conference this year, so I hope to catch up and I'll be pushing the Pi!

/Dextrus