Teaching a course in the fall semester in the Netherlands

[pe...@vdbrand.nl]

Hello everybody,

I'm Peter van den Brand, a software developer from the Netherlands. About a year ago I came across CodeWorld, and toyed with the idea to teach programming to a couple of kids. It didn't happen last year, but this year I'll be teaching about 5 students aged 11-12, in 16 weekly classes, taking 2 hours each. I'm hoping to get all the way to games, though I realize this might be a little ambitious. I don't want to skimp on the fundamentals. If there's interest I will extend it by another half a year.

I found a lot of very good resources already. The gallery is great, also to get kids interested. I've got access to the google drive with the topic outline, handouts, etc etc. I came across the Parkside webpage and the youtube videos. All excellent resources to base my own course on. It really matches the goals and focus I want to have.

To get better acquainted with CodeWorld, I wrote a simple Pacman-like game this morning: https://code.world/#PeC8Qqzh1zYSz31eIR0qHJg. It's not as tidy as it could be, but it does what I intended. I started with an interactionOf right from the start, and added more and more state and behavior as I went along. However, once the program got a little bigger, I quickly got tired of adding another field to State, because I had to add it in like 10 different places (everywhere where I pattern match on State and construct States). I refactored the code 2 or 3 times to work with data declarations that allowed more concise functions, and it's still not great. I was really trying to write my functions in such a way that I needed the least pattern matches, but could still generalize some things. The "duplication" of distanceToGhost / distanceToFood / distance is one example that's still left in the code, ideally I'd refactor that such that I only need one distance function. Tuples of tuples of tuples get pretty confusing too...

In plain Haskell, lenses would probably be the best solution, but that is too complicated to teach to kids I think. I briefly tried record syntax, but that didn't improve things much.

Perhaps I'm getting ahead of myself, and the games that kids will come up do not require enough state to get too complicated. Did anyone else run into this problem? Anyone have suggestions on how to improve the design of the program with complex state?

Thanks,

Peter

[Chris Smith]

Hi Peter,

Great to hear about your class.  Sounds very exciting!  I'll try to share the experience I have, but every class seems to go differently.  So be ready to throw my advice out the window if it's not what your class needs.

I think how far you get in your class depends very much on your goals.  If your goal is just to motivate or inspire, then you can push pretty far.  I've taught students up through fractals and had them customize an example of a fractal in a single one-hour class!  However, none of those students were able to work independently after I left the room.  That wasn't the goal.  To do the motivation thing, you just need to coach them through the motions of programming, and explain the high-level view of what they are doing.  If you wanted to cover games in this sense, I'd (reluctantly) suggest you build for them a general template of a game, and have them write the parts as you explain them.  Try to leave as many chances as you can to make creative choices along the way, but the overall program structure would be fixed.  This is a pattern followed by many motivational programming activities.

On the other hand, if your goal is to build all of the skills they need to continue beyond your class and work creatively and independently with CodeWorld, then you are probably being extremely ambitious to try to reach games in 16 weekly classes.  Having a small class will help a lot, but in my (typically much larger) classes, I struggle to even get most students to understand and work creatively on animations in a weekly semester-long class.  We're working this summer on creating an official CodeWorld curriculum for a daily elective class, and the hope there is to prepare about 180 days of content (!) at around 40 minutes per day.  Our current outline begins simulations at day 100, and games around day 140, give or take.  That's likely what you need if you want to teach thoroughly and leave kids with lasting skills.  Learning just takes time.

About managing state: first of all, yes, managing an explicit state machine is a pain in the butt.  It's not the right approach to a larger-scale problem.  Doing it this way in CodeWorld is basically an admission that students won't create games with extremely complex state.  But your state isn't so complex, and I think we can do a little better.

The main suggestion I'd make for your game is that each type of game object should own all of its own state, including its own supply of random numbers.  You can seed a new random number sequence from a single number, using the function called "randomNumbers".  So I think each ghost should have a separate random number stream.  You no longer need to thread random numbers through a list recursion, so you can use a simple list comprehension to move the ghosts.

I could make a few other small suggestions.  For instance:

    eatenByGhost = not(empty([ g | g <- ghosts, distanceToGhost(pac, g) < 1 ]))

can be replaced by

    eatenByGhost = any([ distanceToGhost(pac, g) < 1 | g <- ghosts ])

But I think the fundamental problem you're running into is a reasonable one, that you just cope with and mitigate.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/6eedfceb-8a8c-40c7-8dd8-15040e58df3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pe...@vdbrand.nl]

Hi Chris,

Thanks for your quick reply!

Great to hear about your class.  Sounds very exciting!  I'll try to share the experience I have, but every class seems to go differently.  So be ready to throw my advice out the window if it's not what your class needs.

I don't have any experience teaching to kids, so any advice is welcome! 

I think how far you get in your class depends very much on your goals.  If your goal is just to motivate or inspire, then you can push pretty far.  I've taught students up through fractals and had them customize an example of a fractal in a single one-hour class!  However, none of those students were able to work independently after I left the room.  That wasn't the goal.  To do the motivation thing, you just need to coach them through the motions of programming, and explain the high-level view of what they are doing.  If you wanted to cover games in this sense, I'd (reluctantly) suggest you build for them a general template of a game, and have them write the parts as you explain them.  Try to leave as many chances as you can to make creative choices along the way, but the overall program structure would be fixed.  This is a pattern followed by many motivational programming activities.

This is definitely NOT what I want to do.

 

On the other hand, if your goal is to build all of the skills they need to continue beyond your class and work creatively and independently with CodeWorld, then you are probably being extremely ambitious to try to reach games in 16 weekly classes.  Having a small class will help a lot, but in my (typically much larger) classes, I struggle to even get most students to understand and work creatively on animations in a weekly semester-long class.  We're working this summer on creating an official CodeWorld curriculum for a daily elective class, and the hope there is to prepare about 180 days of content (!) at around 40 minutes per day.  Our current outline begins simulations at day 100, and games around day 140, give or take.  That's likely what you need if you want to teach thoroughly and leave kids with lasting skills.  Learning just takes time.

My goal is to teach them lasting skills. Those skills include decomposing problems and thinking abstractly, not just knowing the right incantations to make a computer do something.

My rough planning was as follows. First 7 weeks go up to and including animations. These weeks will roughly follow the classes for CodeWorld I you did at Parkside, though I will have 2 hour sessions instead 1.5 hours per session. I'm hoping to do the first three Parkside classes in two sessions, the next four in another three sessions. Then animations and working on a scene from a book or movie in the last two. Students will have one week of holidays, and I expect/hope they will work on their animation project in that week. Counting the total hours, 7 * 2 = 14 hours, for Parkside you did 10 * 1.5 = 15 hours. So I figured it should kind of work out.

Then the second half of 9 classes to get up to games. These will roughly follow CodeWorld II. I am planning to take a little less time on functions (but only if the students are good enough!), skip or at least postpone fractals, and possibly introduce interactions before physics (gravity, bounce). The step from animations to interactions is quite small, so I'm hoping one or two sessions or so is enough for that (correct me if I'm wrong!). After the classes are over, they will have two weeks of Christmas holidays. They can work on their game in those two weeks. We could get back together one final time after the holidays, or continue the classes.

I know at least 2 kids are very bright and pretty good at math. I don't know about the other kids. I'm hoping the small group will allow the quick kids to get to games at the end, and possibly have the other kids up to animations or perhaps simpler simulations.

About managing state: first of all, yes, managing an explicit state machine is a pain in the butt.  It's not the right approach to a larger-scale problem.  Doing it this way in CodeWorld is basically an admission that students won't create games with extremely complex state.  But your state isn't so complex, and I think we can do a little better.

I googled a bit last night to see how game developers do this in other languages. Turns out that they're just using different variations of the same theme: mutate some big global data structure. Pretty much what CodeWorld does, just with a few more tools than what CodeWorld offers (hashmaps, OO, etc), but also with a lot more headaches that come with mutability. A better record system in Haskell would be great though, and alleviate some issues. One can always wish...

The main suggestion I'd make for your game is that each type of game object should own all of its own state, including its own supply of random numbers.  You can seed a new random number sequence from a single number, using the function called "randomNumbers".  So I think each ghost should have a separate random number stream.  You no longer need to thread random numbers through a list recursion, so you can use a simple list comprehension to move the ghosts.

That's very helpful, I'll definitely try that.

 

I could make a few other small suggestions.  For instance:

    eatenByGhost = not(empty([ g | g <- ghosts, distanceToGhost(pac, g) < 1 ]))

can be replaced by

    eatenByGhost = any([ distanceToGhost(pac, g) < 1 | g <- ghosts ])

But I think the fundamental problem you're running into is a reasonable one, that you just cope with and mitigate.

 Will do. Thanks again for your feedback!

[pe...@vdbrand.nl]

Btw, I spent a little bit more time improving my implementation: https://code.world/#PAfe63pxi3zum3giTpYE0JA

This version uses a couple of simple type classes, and it allowed me to generalize the movement and distance functions the way I wanted, at the expense of some extra boiler plate and complexity. This will be a bridge too far for the class of course.

I also used the randomNumbers function, though in a slightly different way than suggested.

[pe...@vdbrand.nl]

Today I taught the first class, and it went great!

The kids got the hang of drawing pictures with circles, rectangles, and colors pretty quickly. After I did the "striped ball" with them, they all independently wrote a program that draws a funny smiley: https://code.world/#PUaRe4lH88uUAYZvgS1cJ5g. Letting the students make a smiley was a very good idea, because they can be very creative with just small changes. For example, one student turned one eye into a rectangle and it looked like the ;-) smiley. When someone wanted to make the round part of the tongue, it looked like a clown's nose because it was drawn in the center (before adding the translated function call). In short, they had a lot of fun experimenting and are all enthusiastic.

One minor issue was the fact that CodeWorld requires a google account. I asked the parents to make sure the kids had one before the class. However, two kids couldn't remember their account name or password, and a third kid had to confirm that they owned the google account using another email address, and he didn't know how to read his email from the laptop. It took at least 20 minutes to create a new google account for them and get it all working. I would personally appreciate it if students could create an account (just username and password) on CodeWorld directly, but in the end we were able to get through all the material I wanted today.

Regards,

Peter

Op donderdag 13 juli 2017 14:38:46 UTC+2 schreef pe...@vdbrand.nl:

[Chris Smith]

Thanks for the feedback.  Glad to hear that the class went well!

Yes, I've always intended to give more options for login.  Unfortunately, it's a bit of a minefield in many countries to allow children to create accounts and identify themselves.  Since so many schools (in the U.S., anyway) are part of the Google Apps for Edu, kids there have school accounts, and Google gets to hire the lawyers to make sure it's done right!  If there is a different SSO provider that would be more convenient in other countries, it may be a better option to add that.

Otherwise, if they have their own devices, perhaps I could make it easier to load and save files locally?  That would be useless for me, since I almost always teach in places where students grab a random device from the cart on the way in the door.  But it might work in a different setting.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/0d5ed851-53c5-44fd-b921-5573356c04ab%40googlegroups.com.

[Peter van den Brand]

I didn't realize it's an issue for kids to create accounts. We did notice that Google did not accept their actual birth dates, because they are too young. They had to try again with another birth date. Anyway, we're up and running now without problems.

I like the fact that their work is stored online instead of locally. It makes it harder to lose all their work just because the laptop broke or something.

Next time I'll ask them explicitly to make sure they can sign in on http://code.world using the device that they will bring, and to make sure they know their account name and password. That would avoid the issue as well.

To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To post to this group, send email to codeworl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5PvJrRzF2YgrtMHDyUwpu8Mo714tEbuaW%2Bs2%2BzA8p40ESBw%40mail.gmail.com.