teaching kids how to program
Pages: 12
I'll be working as a Teachers assistant in a Tech/Engineering course at a middle school. The teacher's expertise is in Mechanical engineering. He wants to incorporate programming into the course, and I need to brainstorm ideas for how to approach this. I was wondering if anyone has any thoughts on this. I know some of you are in this age group yourselves. Some of you may have taken similar courses. Keep in mind there is a limited amount of time they have, and the idea is that it's fun.
What programming language should I teach?
How can I make it fun?
What sort of projects?
To what extent should I cover syntax etc, before starting fun projects?
Should the framework for the projects be nearly complete, leaving the fun parts only to them? Or should they build from the ground up?
What sort of introductory concepts about programming in general should I cover?
How about apps?
What programming language should I teach?
How can I make it fun?
What sort of projects?
To what extent should I cover syntax etc, before starting fun projects?
Should the framework for the projects be nearly complete, leaving the fun parts only to them? Or should they build from the ground up?
What sort of introductory concepts about programming in general should I cover?
How about apps?
Last edited on
closed account (Dy7SLyTq)
| What programming language should I teach? |
i would say scratch. its this dinky little language that comes with raspberry pi meant to teach kids programming. http://scratch.mit.edu/projects/editor/?tip_bar=getStarted you want something like that. you learn things like variables, ifs, loops, and events to get the cat walking. i *think* you can intergrate it with hardware which would work well with your egineering thing.
| How can I make it fun? |
i cant think of anything more fun than programming a cat avatar
| What sort of introductory concepts about programming in general should I cover? |
i would say all of the universal stuff like functions, data structures, variables, data flow, io
You are in for a lot of work.
I actually did this with a 6th grade computers teacher. My project was designed to be very simple -- a networked pente game with graphics. Naturally, the vast majority of the working code was written by me and my teammate. The children were to play with simple networking (which Python makes pretty easy) and sprites.
It didn't end too well. (In part because my teammate bailed on us.)
What happened is that I was able to get the children to implement some basic animations with sprites (making some really cool pictures -- think old-time "kaleidoscope" programs) using Python (with PyGame). They enjoyed making the computer do what they want, react to their input, and understand basic flow control and variables.
As for language, both Python and Tcl/Tk are good.
I know nothing about Scratch, but it looks like it is worth your time to peruse as well.
Remember
Make it stupidly simple. Pick a language where syntax is not going to be a significant issue -- where it can be picked up as you go.
Make sure it has some sort of fun feedback. Kids like seeing their creations do cool stuff. Like neko (http://webneko.net/) -- meaning you'll want a SDL event system or equivalent.
For the grade level, dive right into projects. Make sure you have your smartboard/elmo/whatever you are using to show your students what you are doing -- type in the code that does stuff for them to see, explain (remember: stupid as dirt), then show it in action. Have the kids to the same kind of thing. Then let them play with it to see how they can modify the code to behave differently. (Remember: children will try a number of different things, and you will have to spend a lot of time working through what they are trying to do to help them. Don't be afraid to redirect if they want to do something not stupidly simple.) Then move on the next step.
Framework -- you must build everything. The children should only be handling small (stupidly simple) parts of the program. Make sure to design it so that they have some flexibility in program behavior.
Make sure to give them the libraries they need to do stuff. For example, a linear interpolation will be waaaay above their heads. Give them an interpolator and show them how to use it. How it actually works is irrelevant.
The only concepts they must understand are:
variables
input
program flow (if/case, loops, functions).
Apps? What kind of devices will they be programming? Not the standard PC desktop found in classrooms?
I actually did this with a 6th grade computers teacher. My project was designed to be very simple -- a networked pente game with graphics. Naturally, the vast majority of the working code was written by me and my teammate. The children were to play with simple networking (which Python makes pretty easy) and sprites.
It didn't end too well. (In part because my teammate bailed on us.)
What happened is that I was able to get the children to implement some basic animations with sprites (making some really cool pictures -- think old-time "kaleidoscope" programs) using Python (with PyGame). They enjoyed making the computer do what they want, react to their input, and understand basic flow control and variables.
As for language, both Python and Tcl/Tk are good.
I know nothing about Scratch, but it looks like it is worth your time to peruse as well.
Remember
Make it stupidly simple. Pick a language where syntax is not going to be a significant issue -- where it can be picked up as you go.
Make sure it has some sort of fun feedback. Kids like seeing their creations do cool stuff. Like neko (http://webneko.net/) -- meaning you'll want a SDL event system or equivalent.
For the grade level, dive right into projects. Make sure you have your smartboard/elmo/whatever you are using to show your students what you are doing -- type in the code that does stuff for them to see, explain (remember: stupid as dirt), then show it in action. Have the kids to the same kind of thing. Then let them play with it to see how they can modify the code to behave differently. (Remember: children will try a number of different things, and you will have to spend a lot of time working through what they are trying to do to help them. Don't be afraid to redirect if they want to do something not stupidly simple.) Then move on the next step.
Framework -- you must build everything. The children should only be handling small (stupidly simple) parts of the program. Make sure to design it so that they have some flexibility in program behavior.
Make sure to give them the libraries they need to do stuff. For example, a linear interpolation will be waaaay above their heads. Give them an interpolator and show them how to use it. How it actually works is irrelevant.
The only concepts they must understand are:
variables
input
program flow (if/case, loops, functions).
Apps? What kind of devices will they be programming? Not the standard PC desktop found in classrooms?
Thanks for the input.
The teacher thought the kids might like to build apps for their smart phones, but I imagine some of them have ios and some android, and I'm not very familiar with development for either. Ideally if we built smart phone apps, we would develop cross platform apps, and be able to get the apps on the students phones by the end of the semester. I thought if I go this route, maybe use something like unity.
One issue that I'm not sure about is that we cannot install anything on the computers ourselves.
Another possible project I thought of was to develop web based games with java script.
But I found out we have some programmable robots. The environment for programming them is a C++ interpreter. So since I have to explain the basics of C++, maybe I should stick with C++ for another project. Maybe use SFML, or maybe even a basic OpenGL, and provide almost everything for them except movement etc. The problem is that the teacher wants me to teach something that the students can replicate on their own at home. They may be frustrated when they get to play with a cool game at school, but then find that on their own, they can't really make much of anything.
Maybe scratch is something I should consider.
| Apps? What kind of devices will they be programming? Not the standard PC desktop found in classrooms? |
The teacher thought the kids might like to build apps for their smart phones, but I imagine some of them have ios and some android, and I'm not very familiar with development for either. Ideally if we built smart phone apps, we would develop cross platform apps, and be able to get the apps on the students phones by the end of the semester. I thought if I go this route, maybe use something like unity.
One issue that I'm not sure about is that we cannot install anything on the computers ourselves.
Another possible project I thought of was to develop web based games with java script.
But I found out we have some programmable robots. The environment for programming them is a C++ interpreter. So since I have to explain the basics of C++, maybe I should stick with C++ for another project. Maybe use SFML, or maybe even a basic OpenGL, and provide almost everything for them except movement etc. The problem is that the teacher wants me to teach something that the students can replicate on their own at home. They may be frustrated when they get to play with a cool game at school, but then find that on their own, they can't really make much of anything.
Maybe scratch is something I should consider.
Last edited on
closed account (Dy7SLyTq)
unfortunately i dont think you can build cross platform phone apps. android focuses on java (well you can use api but you still would have to use the android api i would imagine) while apple focuses on obj-c with the cocoa framework (you might be able to do this in c++ with the gnu step framework which is like obj-c). windows phones use c# i believe
You should defiantly do something with robotics. Skip over the introductory basics and jump right into designing control loops or else you're just going to bore them to tears. Understanding how and why you do things a certain way is much easier when you have a context to apply them to. Also seeing how a small change in a variable has a drastic change in the outcome of a process is much more interesting when the difference is more then just text on the screen.
If you don't want overhead involved in teaching the kids how to program or if the fact that you can't install software on the computers is too cumbersome (and you can't see the work around to that little problem); then try something called BEAM robotics, that's what I started out on and I'm not that bright.
What ever you end up choosing to do though PLEASE DOCUMENT how it goes, I am begging you here. My fiancee signed me up to be a volunteer STEM instructor for her Girl Scout troop and I am at a complete loss for where to start. They have these pre-fab project kits that are sub par for the age level they are aimed at I have zero teaching experience or training beyond raising my own kid.
If you don't want overhead involved in teaching the kids how to program or if the fact that you can't install software on the computers is too cumbersome (and you can't see the work around to that little problem); then try something called BEAM robotics, that's what I started out on and I'm not that bright.
What ever you end up choosing to do though PLEASE DOCUMENT how it goes, I am begging you here. My fiancee signed me up to be a volunteer STEM instructor for her Girl Scout troop and I am at a complete loss for where to start. They have these pre-fab project kits that are sub par for the age level they are aimed at I have zero teaching experience or training beyond raising my own kid.
| htirwin wrote: |
|---|
| The teacher thought the kids might like to build apps for their smart phones, but I imagine some of them have ios and some android, and I'm not very familiar with development for either. |
I just did and that's a pretty neat idea! I especially like the inclusion of the function block. I'm honestly more interested into what this could turn into then what it is out of the box. It's almost like they dumbed it down too much for my liking since it doesn't have a simple logic gate and input sensor. At four a child can understand a simple if then statement in the "If they press this button on the remote, the TV turns on. If that doesn't work throw an exception, i.e. ask Mommy or Daddy for help" kind of way.
I don't think we should be teaching controversial ways of dealing with error states. At that rate exception handling would never become deprecated within my lifetime.
Last edited on
LOL! I'm not just saying that, I'm actually laughing at my end EDIT: Not at your opinion about exceptions by the way, but at the thought of telling my self NOT to teach my 4 year old a concept that took me almost a YEAR to understand the purpose of. IMO there's nothing wrong with exceptions as long as you recognize that you can't handle every single one and sometimes it is in fact better to just give up. If nothing else you can't always just return from a function when an error happens, some variables need to be deleted or released and in the case of things like passwords or digital keys the memory should be overwritten before it is released to the OS so as to prevent a Read-After-Delete exploit. In those cases try and catch are much cleaner then goto.
Last edited on
As controversial as exceptions are, I will state my reasons for disliking exceptions.
The issue with exceptions is not the handling aspect, it's the throwing aspect. Not because of inefficient implementations (I could care less about efficiency), but because it is conceptually wrong (in my opinion) to throw exceptions when you cannot deal with an error.
Returning error codes went out of favor for the same reason: they don't do anything to prevent the problem from happening in the first place.
Ideally, interfaces should be designed such that it is not possible to use them in a way which will lead to a situation that is erroneous. An example is Java's InvalidArgumentException - why does the argument list accept types which can be in erroneous states?
I don't want to discuss this further because we have already had an entire thread on this in the past - this is just a refresher ;) Let's underail this thread. Sorry for derailing it in the first place.
The issue with exceptions is not the handling aspect, it's the throwing aspect. Not because of inefficient implementations (I could care less about efficiency), but because it is conceptually wrong (in my opinion) to throw exceptions when you cannot deal with an error.
Returning error codes went out of favor for the same reason: they don't do anything to prevent the problem from happening in the first place.
Ideally, interfaces should be designed such that it is not possible to use them in a way which will lead to a situation that is erroneous. An example is Java's InvalidArgumentException - why does the argument list accept types which can be in erroneous states?
I don't want to discuss this further because we have already had an entire thread on this in the past - this is just a refresher ;) Let's underail this thread. Sorry for derailing it in the first place.
Last edited on
I don't see how anyone would say it was you instead of me who derailed this thread but I'll stop.
You have to admit though, that robot would be more interesting with some kind of sensor and control loop.
You have to admit though, that robot would be more interesting with some kind of sensor and control loop.
They already have robots like that, I've played with them at multiple science museums. The goal of Primo is to be used by children of a much younger age.
closed account (N36fSL3A)
Actually me being a student where robotics is incorporated into the tech system I can say that 80 percent of the kids actually hate programming. (well in my school).
Going against what they say, I'd say you should do something sort of like NXT and robotics.
Going against what they say, I'd say you should do something sort of like NXT and robotics.
@ Lumpkin: That's perfect, you break the class into teams of five with one kid who likes programming each. Ideally in teams that small you would only want one programmer anyway, otherwise you're mashing code together from different authors with different styles and that's something us grownups even have trouble with.
Experienced programmers ("grownups") have problems with mixing styles because they have actually developed styles.
Inexperienced programmers ("kids") don't have problems with mixing styles because they have not even developed styles yet - they have problems with mixing knowledge and what little experience they have, as well as not properly communicating what is done and what needs to be done.
Inexperienced programmers ("kids") don't have problems with mixing styles because they have not even developed styles yet - they have problems with mixing knowledge and what little experience they have, as well as not properly communicating what is done and what needs to be done.
Last edited on
closed account (N36fSL3A)
My teacher did something similar. But since NXT isn't really programming is just drag and drop, no mashups of styles will occur.
Of course you could use Python instead of NXT if you want, then give them some sort of micro-controller or mini-PC like the Arduino/PI. They could choose parts and compete in some type of competition. That's actually what my schools Robotics team does. Except they compete with teams around the state. (I was supposed to be a part of it but I signed up too late >_>)
----------------------
Just make sure not to do anything corny; people get disinterested fast.
Of course you could use Python instead of NXT if you want, then give them some sort of micro-controller or mini-PC like the Arduino/PI. They could choose parts and compete in some type of competition. That's actually what my schools Robotics team does. Except they compete with teams around the state. (I was supposed to be a part of it but I signed up too late >_>)
----------------------
Just make sure not to do anything corny; people get disinterested fast.
Last edited on
@Lumpkin: I did not realize there was controversy over whether using drag-and-drop IDEs was considered programming or not - I always thought it was considered 'real programming'.
Last edited on
Pages: 12