Teaching Youngsters Programming

Quote from boley on December 1, 2011, 16:31
Another wooly concept is moving or sizing things by adjectives rather than hard numbers.

That's something uncommon too. I'm not sure what technology you're based on, or how robust your parser is, but you might want to look at Inform's parsing code. Indeed, one of the first things I thought when I saw it was "cool, Inform with graphical manipulation"

Simon

Lots of interesting ideas here.

My concern is that since RPi is a full on computer that can access the Internet, there will be a degree of distraction.

This afternoon, my 11 year old daughter and I built a small computer called Fignition, which has a truly dreadful chorded keyboard and runs Forth. There were some frustrating incidents when we tried to save the editor's content and ended up wiping it instead (twice), but in the end w worked it out. It's a little like a Jupiter Ace I suppose; monochrome, with a simple command line interface. A very 80's home computing experience. Yet despite that, my daughter is enjoying it and has mastered the keyboard (only 8 keys!) already. It's a shame neither of us understand Forth (very arcane)!

The point I am trying to make is that IDEs and advanced languages are unnecessary, as I think some other posters said. Keep it simple. Go with an easy to use language (what's wrong with a structured BASIC without line numbers?) with high level access to hardware and let the kids explore.

The R-Pi plays Quake 3, like any learning is going to get done, particularly if they find deathmatch!

I think the trick is to pick the right level of language for the person learning, there needs to be a balance between the work and the pay off.
i.e. Basic/logo, the work is simple but the pay off is limited, C# is harder but you can do a lot more.
For someone learning for the first time, it needs to be nice and simple but give a great payoff quickly to get them hooked (the feeling of...if I just make this little change here it'll be better...ooo I could do this too and it'll be even better).

For older ones, disconnecting the network and ensuring there are no games is probably a good plan!

Quote from meltwater on December 20, 2011, 14:03
I think the trick is to pick the right level of language for the person learning, there needs to be a balance between the work and the pay off.
i.e. Basic/logo, the work is simple but the pay off is limited, C# is harder but you can do a lot more.
For someone learning for the first time, it needs to be nice and simple but give a great payoff quickly to get them hooked (the feeling of...if I just make this little change here it'll be better...ooo I could do this too and it'll be even better).

+1, that's my main gripe with "modern" programming environments in general (on PCs) - sure, you can compile the samples (fingers crossed), but by the time you would manage to make a significant independent improvement/own work from scratch, you'll long be buried under miles of make config files, arcane error messages and obscure API references... *sigh*

Quote from meltwater on December 20, 2011, 14:03
For older ones, disconnecting the network and ensuring there are no games is probably a good plan!

-1, I really don't think that will make a difference. Yes, the first instinct is to play something that is already done, not to program - which is why it's your (/my/our) responsibility to introduce those kids to what programming looks like, to make sure they experience that (and that they get a rewarding experience). But beyond that, you're not going to be able to force anyone to "learn instead of playing" by denying them access, if their interest has not been sparked by what they were shown.

The "more work, less play please" approach failed and keeps failing spectacularly in the traditional education - where it is the actual method unfortunately - and results mostly in memorizing just enough for a pass grade until the next exam, then wiping most of it (lather, rinse, repeat). Of course, I can only talk about what I've seen personally, but I can tell you that none of those who weren't interested learned any programming (or anything else for that matter) in the end, and none of those who did learned it at the school because they were supposed to, but at home because they wanted to... just my $0.02.

I'm currencly reading the python tutorial: http://docs.python.org/release/2.4.4/tut . It is certainly not a way to get any youngster interested in the language!

"Some simple generators can be coded succinctly as expressions using a syntax similar to list comprehensions but with parentheses instead of brackets. These expressions are designed for situations where the generator is used right away by an enclosing function. Generator expressions are more compact but less versatile than full generator definitions and tend to be more memory friendly than equivalent list comprehensions. "

Sometimes I think maybe we put the cart before the horse, trying to teach people to write programs before they can read them. Imagine trying to teach a person to write a proper narrative in a foreign language without first at least being able to read simple sentences. An Integrated Learning Environment might be more important than an IDE, where first the learner is presented with working code, and is taught the meaning of each verb or structure, one by one by example. The "fun" is in learning to hack a fun program. Good programming skills come from reading good programs in IMHO.
I can imaging a bit of working code and questions like, "How many balls will be bounced by this program? Can you change the color of the second ball? What would happen if you move the third line outside the loop? I remember reading some very good tutorials have been written in that style.

A couple of other thoughts.

"GOTO" may be a dirty four letter word, but we don't abandon english because it contains a lot of four letter words that can cause trouble. We explain that these words can cause harm if used in the wrong context and move on.

Line numbers like verses in the Bible, might not add anything functional to a language but it sure makes it easier to direct someone's attention to a particular part of the text/code.

Any teaching system that requires much setup i.e. setting environmental variables, or is in a language that is completely foreign to the learner is a non-starter for most students. There are those students that excel in languages in general (I suspect most of the members of this forum are in the top percentile) but don't think for a minute that is the norm. Simple forgiving syntax and grammar trump adjectives like "modern", "powerful", "enforces" and "strict" when referring to a beginning programming language.

Riding a trike and bike didn't warp me such that I couldn't learn to drive an automobile later. Fill in your own ancient simple vs modern powerful computer language into the analogy.

About "Forth". It is really an elegant, simple, and yes, even powerful language. But like using RPN calculators, your brain almost has to be wired a certain way to use it naturally.

Wooloomooloo - Yeah you are right, you can't force them to program (and it's not the way to go either). The multi-tasking nature of modern os does mean distractions will be around [fact of life], but they either want to do it or they don't I suppose. At least, a lot more information is available when they run across a problem they can't solve.
piglet & boley - In some ways, tutorials written by their peers can be far more valuable, just like you can read two different books on the same language, one can explain things just right for you, but not for someone else.

It's always a catch22 with learning a language, particularly a complex one since you have to build up a lot of knowledge (which doesn't logically link-in) until you have a critical mass which allows you to build it all together of how things work.
As you suggest, it is very much like learning a language , you have to learn the basics to get by and then study a lot harder to master the next level. Learning any language though, will equip the learner to learn other languages, and importantly the way of thinking which is key.

I just wonder how different it is for kids now, where modern games are so in advance of a few lines of code (although I guess it was the same in some ways in 80s, so perhaps I'm wrong). I suppose most things now will require use of other code to support and make it function. It is almost a different discipline, where making use of building blocks and adapting code is probably just as useful as being able to writing things from scratch. Probably the skill of reading and understanding code is more important in some ways.

Simple programming languages are great, and probably ideal to teach with, it's only later that they will probably need to look at more complex ones (now being equipped to learn them) to take their skills to the next level and do more.

Not trying to stir anything up or hijack this thread, but I'm posting a link to something I think may be required reading for anyone considering using game play techniques to encourage students to learn.

http://www.wired.com/magazine/.....cker/all/1

I'm not quite sure what lessons can be learned by "Cow Clicker", good or evil, but at a minimum it reminds me to consider unintentional consequences. After reading, be sure to go back and click on the word "cow" in the article.

I started this topic way back. Since then I have been lurking and contributing little to the forum. However while doing my day job I have also been working on some resources and ideas.

I am a secondary teacher with little Computer Science knowledge but I do have a little programming experience. As such I have focused on this area and produced some materials and tried them with my club at school. This went down pretty well (I gained more students than I lost!). I think I have a couple of fairly unique ideas and as such I am considering publishing the first book for June 2012 if others feel it worthwhile. However, I am still unclear as to how go about this. I am in discussion with a couple of publishers (but they are very slow) and I am considering having them printed myself. Then there is the alternative to simply share the resources as Open Source. As I am undecided as to how to proceed I am afraid I can only share samples at this stage. Nevertheless I would be very interested in the opinions of other people on this forum.

The proposed support website link is below. I would be especially interested in feedback on the sample chapters for Book 1 and any comments on the last section on the Info page of the web site if anyone has the time. I would also love it if somebody with a RaspPi and Python 3 installed could try running main.py from the source files for Chapter 9 and let me know if it has the oomph to cope with the game.

http://codingclub.cuteseal.co.uk

Great stuff. Browsing through it makes me all tingly thinking back to my wondrous experience learning basic. there be magic !

Quote from Sciman on December 22, 2011, 11:16
I would be especially interested in feedback on the sample chapters for Book 1 and any comments on the last section on the Info page of the web site if anyone has the time.
http://codingclub.cuteseal.co.uk

I admire you for taking on the project and wish you the best. I think writing for the people you know will probably be the most effective use of your time, but that may mean that your book has a more limited audience. My comments are based on the people I know so, they may or may not be useful to you. (I have a number of years of experience in translating technical jargon to ordinary language, but I'm only an average un-technical writer.) So here's my advice based on your first chapter:

(1) Find a brutal editor, preferably someone you like, that you can easily forgive. Error on the side of taking their advice, but in the end it is your decision as to what should be in or out.
(2) Minimize. For example the section titled Python 3 could be simply reduced to "The programming language we will be using is called Python." (Think like a movie maker. "Is this scene, for all its amazing glory, required to move the story forward?")
(3) Avoid using words and terminology not a part of ordinary conversation with a 10 year old or your mother. "Theory" and "Interface" make my grown friends eyes glaze over. When in doubt about how to refer to something, go to a ten year old, your spouse, friend or mother who isn't "into" computers and point at something and ask them "what is that?" Remember that verbs like "execute" have a loaded meaning in everyday conversation and reading where your student spends most of his time. While students certainly do need to learn techno speak so that they can access and understand other resources, I would put them in side bars or better yet save them for a later chapter or book.
(4) You are right about avoiding polymorphism, overloading..., and I hope you can come up with friendlier terms than "classes" and inheritance. 20+ years later they still make my skin crawl, but I offer no alternatives, sorry.
(5) Simplify screen shots. They are realistic, but include a lot of distraction that have nothing to do with the lesson at hand. Is there any way to turn off the Python start up garbage? ie. "I'm Python, I have silly version numbers and did you know that time and date can be expressed in odd formats and there are ways to get to a lot of information about me and my friends that you wouldn't read if I paid you." If not, you may want to mention they can safely ignore it.

Anyway, that's my two cents (or pence) worth, and you often get what you pay for. Do not let cheap shots like this discourage you. :-)

Thanks boley for taking the time. It is much appreciated. I usually make several redrafts of work sheets but always start with what I want to get across. Your points are well made. Points 1 & 3 are what encourage me to use a publisher. Points 2 & 3: I have on the top of my to do list to change the code boxes and screen shots to generic colour output from IDLE whenever possible and also to hack the words down to their bare minimum while carefully checking for language usage. I am also thinking of creating a fold out glossary as I believe there is a need to teach key words so that students can look up solutions effectively on the internet. I will look in to Point 5.

I posted here, but do not wish to hijack the discussion on what is the best way to teach youngsters to program so if other people have the time to look at my stuff I am eternally grateful but it is probably better to message me directly unless my offering can be used as an example to make a particular point of what is appropriate or not in teaching youngsters computer science.

Not sure about the documents, browsing on a godawful tablet. I would strongly suggest using the 'standard' vocabulary for oo terms though. 'factory' has a common, very specific meaning already.

otherwise, looking very good.

Yep. The terms make your skin crawl because they were badly introduced to start with. No need to reinvent the vocabulary, just to introduce it nicely. It feels empowering to come across terms you just learned in real life, as opposed to being fed the baby version.

Oh dear! Thanks for pointing that out tufty. That is what happens when you teach yourself and do not have a Computer Science education behind you!

While reflecting on the last few posts and while teaching my Club last term, a few important issues have surfaced in my mind with regard to teaching students their first computer language. I know that students can be introduced to Computer Science earlier in a more visual way for instance but eventually I want some students in the UK to enjoy writing their own programs as much as I do:

1. Is Python a good language for kids to start with? Having only recently picked it up and then taught it I think it as an excellent first language especially with IDLE (the bundled IDE) and I hope that the samples I have posted show how quick students and newcomers can make progress. I also have a strong preference for Python 3

2. Is it useful to teach OOP early? Here I am beginning to understand why others think not. There are a lot of complexities, a lot of boilerplate code, lots of technical vocab and the usual analogies of templates and blueprints cause more problems than they solve. On the plus side program design matches how real objects are built out of components. It is also easier to (teach how to) design bigger apps this way than, say, functional programming. Also computer games have lots of repeated objects and building classes is by far the best way of doing this.

3. Speak like a programmer or like a generic human? This is very difficult for me. I learnt to use a Word processor on an Amstrad PCW using Locoscript. I read the user manual. This used all the industry key words and stood me in great stead when changing to other word processors as I could quickly look up how to justify text. I am a firm believer in having the technical vocab. On the other hand a lot of the technical vocab in computing is alien to youngsters and that is why in the bad old days teachers found it hard to teach spreadsheets to students in ICT lessons as the contexts in the textbooks were all business oriented and the students were often confused before they started. I am starting to think that the question we should be thinking is do we want first time programmers to learn to speak like programmers or think like programmers? This is a no brainer and gives me the freedom to whenever necessary ignore horrible jargon and even use the factory analogy when it helps students, even though I now know that later this will need correcting. We do this in Science teaching all the time! (I am a Chemistry teacher by trade.) In other words I am coming to think that bole is completely correct in his 3rd point, four posts above.

Quote from Sciman on December 23, 2011, 10:00
1. Is Python a good language for kids to start with?

Is it ever. Python makes an excellent language for teaching (and it's an excellent language overall, to be honest). Why? Here's a few reasons :

• It's uncluttered by syntax, and consistent[1]. Other languages have curly brackets here, square brackets there, round brackets over here, semicolons all over the place, and even commas can get you in trouble.
• You get "instant feedback" through the REPL.
• It's a dynamic language - introspection and debugging are built in.
• It's not crippled. Unlike *cough* some other languages *cough* it doesn't restrict you to some "beginner[2] level" of what programming is. From if/then/else to continuations and tail call optimisations, it's pretty much all there.

Quote from Sciman on December 23, 2011, 10:00
2. Is it useful to teach OOP early?

It's a gnarly issue, this one. OO (or, at least OO as implemented by C++/Java and friends) has largely failed to meet a lot of the promises made early on - code reuse is still largely restricted to "I will deliberately design a generic component" (a task that is particularly hard to do, and usually ends up with something as totally easy to understand as C++'s STL[3]). On the other hand, most languages have mixed up "classes" with "structures", and in place of making data structures and the functions that manipulate them, we instead largely make classes, and encapsulate the manipulator functions inside the class. I'd probably start by explaining user-defined structures, defining a few methods to create, destroy and manipulate, and then bring in the concept of encapsulating it all in a class. I probably wouldn't look at inheritance or polymorphism at the start.

To really teach OO, I would still suggest using smalltalk as the initial base language, then look at other possible implementations to see the pros and cons. Other implementations I'd look at include Python, Ruby, Javascript, CLOS and Self, and potentially some of the purely functional implementations of OO that have been done in scheme. It would, of course, be possible to build most of the latter in Python, but implementing a parasite OO system on an already OO language is a bit - well - wierd.

Quote from Sciman on December 23, 2011, 10:00
3. Speak like a programmer or like a generic human?

I'd suggest introducing the proper technical terms, but with an explanation in human terms. It's easier to "see", for example, a class as a cookie cutter than as a structure with a bunch of functions built in and addressed by a vtable. There comes a certain point where most concepts can be explained in terms of other technical terms, but the human aspect remains critical.

OO terminology can be a bit odd, but it was originally intended to be "human" (see Alan Kay's original smalltalk work). It's only really the explosion of pseudo-OO languages like C++ and Java with their bizarre terminology[4] that made a pig's arse of the whole thing.

Simon

[1] I'd also argue that scheme is at least consistent in its syntax, but r6rs introduces square brackets in certain cases. <sigh>
[2] Pronounced "moron"
[3] Or, alternatively, the mongolian language as pronounced by a drunkard with half a tongue.
[4] "private inheritance" for example. WTF?

What's so odd about C++ terminology? I can't say I've ever felt misled by it. I admit the language trades off freedom of OO usage with performance - objective-C for example allows runtime messaging of objects and they either will or wont understand the message, loose typing etc but then it can behave as slow as a scripting language at times.

Most modern games are built on C++ and make great use of the object-oriented paradigm and it works well for the language, the same goes for complex industrial applications.

C++ has the benefits of a strong and logical core foundation, making it simple to teach and expand upon, the best choice of libraries in the industry, close relevance to Linux (as a C++ programmer C is but a subset), it does not lock you in to using OO immediately and is easily used both procedurally or in an object oriented manner. Performance and reliability wise it's the closest one will typically get to machine level code in a higher language.

Naturally it's not a scripting language and must be compiled, but it should always be taught alongside a popular IDE, that will provide friendly and powerful set-up and debugging of projects.

Back to your samples (and forgive me for picking nits but its what I do)

Your example for divide/modulus so that the answers aren't the same 10/3 gives 3 remainder 1

Assigning variables
number=1 does not make number equal to one it puts 1 at the location pointed to by number. This is the first point where your students encounter indirection. make your introduction clear and your subsequent usage consistent.

As I am currently trying to learn python I think your approach is really good and I will be following with interest. (Most python tutorials are not very good)

Please don't be put off by an old fogey like me.

Quote from gimliflea on December 23, 2011, 14:27
number=1 ... puts 1 at the location pointed to by number.

No it doesn't. Not in Python, anyway. It stores a reference to an object representing the number 1 in a named slot in a dictionary. It might be a global dictionary (if 'number' is a global variable), one belonging to an object, in the case of an instance variable, to a class for a class variable, or one of a number of locally scoped dictionaries for a local variable within a function. Or at module scope, or...

</pedant>

A quick bit of news:

I have listened to comments about my proposed short book. I have now split it in two leaving OOP for a higher level one. I have looked at self-publishing which has promise, released the first book as a pdf under a creative commons license that basically says do what you want with it but do not claim it as your own or sell it and yesterday had a meeting with Cambridge University Press who were very enthusiastic indeed about perhaps publishing! - by the first of July!

In any case I just wanted to say thank you for the helpful comments from people and show where the unpolished completed first book is incase it might be of use to anyone:

http://codingclub.cuteseal.co....../book1.php

Sciman said:

A quick bit of news:

I have listened to comments about my proposed short book. I have now split it in two leaving OOP for a higher level one. I have looked at self-publishing which has promise, released the first book as a pdf under a creative commons license that basically says do what you want with it but do not claim it as your own or sell it and yesterday had a meeting with Cambridge University Press who were very enthusiastic indeed about perhaps publishing! - by the first of July!

In any case I just wanted to say thank you for the helpful comments from people and show where the unpolished completed first book is incase it might be of use to anyone:

http://codingclub.cuteseal.co....../book1.php

Excellent news, keep us updated as it would be great see this in print.

Had a quick look, as someone new to python but not programming in general, it won't do any harm for me to quickly run through and get familiar with things.

So far I love it, reminds me very much of the simple programming books I used have when I was younger (no idea how old I was) for the ZX Spectrum.

Back in the stone age (it seems) I used to teach 6502 Assembler to Middle Schools kids - at the dawn of the "IT across the Curriculum" era - very non-pc in those days! Added lots of BBC Basic stuff to the "Blue Book" (non-commercial). Now retired from teaching, the Raspberry Pi will get me coding again!!

I notice no one has mentioned COBOL - thankfully!

A quick bit of news:
http://codingclub.cuteseal.co....../book1.php

I've had a quick look through. Just some random thoughts.

choose a different font for the listings - pl looks like p1

The example in chapter 3 where you show the syntax for defining a class without really talking about OOP is probably going to be confusing to people. I think you get your excuse in about not doing OOP yet and so you are not expected to understand it (especially as you haven't even explained functions yet) too late.

You say "Don't forget it is written for computers to understand, not us". Actually IME code is written for humans to understand not computers - which is why good programmers spend time, a lot of time, choosing good names, laying things out properly, making functions short and so that they only do one thing (which makes them easier to understand) etc etc. It is estimated that good programmers spend at least 10 times more time reading code than writing code.

I think that after chapter 3 you could have a small section introducing basic lists. I think it would work well coming immediately after your 8ball example - which could of course be modified to use a list.

In the etch-a-sketch examples where you are defining line_width and line_length - these aren't really variables (I don't think the values change) so treat them as constants - which means make the names upper-case.

In the etch-a-sketch examples I would personally spell the variables out too so you have player_move() rather than pl_move() - it might make it easier to explain when you go on to talk about turning your example in an object oriented solution. It is pretty easy for someone to go through and say - look at that all these functions and these variables here all really belong to something called player.