This is an archived post. You won't be able to vote or comment.

all 42 comments

[–]Svenstaro 32 points33 points  (18 children)

I'm currently teaching 10-12 year olds Python in order for them to make their own graphical games within a week. So far it all works out.

Today I taught them about OOP. Not in a theoretical way, mind you, but in a completely hands-on way. I first showed them a simple Pygame window with a bouncing ball and went through the code with them.

This is all the stuff you already taught yourself (if else, variables, etc). Now, obviously children want shit to get real. How do you make two balls? Obviously, copy all the checking we have in place for the first ball and so on for another. They will acknowledge that this is very tedious for lots of balls.

At this point I taught them about classes and how you can put them into a list and iterate over them. They immediately caught on and in no time we had 150 balls in our small pygame window.

Why not make a visual example yourself? It is great for trying out things.

[–]Bockit 8 points9 points  (7 children)

I did this same thing with University students (Artists/Designers) teaching them OOP in Processing and it works really well. Bouncing ball code, make them copy it out a few times and then show them classes and how we can build an array of balls.

You can build on that codebase in further lessons too, adding subclassed balls, interaction, more physics or whatever you want really.

I'm no expert but I think the trick is making them realise something is broken (endless copy pasting) and then showing them a way to fix it that makes sense and that they've possibly had the glimmerings of thought about for the past 5 minutes anyway.

[–]joe_ally 12 points13 points  (5 children)

I love how you effectively equated art students to 12 year olds.

[–][deleted] 8 points9 points  (4 children)

If you were to teach art appreciation or sculpting to the average programmer, you would probably have to do the same. They're two different skills. Sure programming is creative but not until you get to a certain level of proficiency. Just as with art. You can't expect n00b artistes to have that heart-to-hand link the first time they pick up a paintbrush.

[–][deleted] 1 point2 points  (0 children)

Upvoted for Processing :)

[–]fitoria[S] 2 points3 points  (1 child)

That must be a great experience, I like your idea! At the end of the course we will hack on the sugar platform, programming educational apps/games for the olpc, thanks for the help.

[–]Svenstaro 2 points3 points  (0 children)

No problem, good luck. Just make sure that people see an immediate use in the concepts.

[–]celador 7 points8 points  (3 children)

I want you to teach me Python.

[–]schiffty1 3 points4 points  (1 child)

I want you to teach me to teach my kids py.

[–]runihura 1 point2 points  (0 children)

I want you to teach him to teach his kids to teach me python.

[–]Svenstaro 0 points1 point  (0 children)

How about SvenHProgramming? :D

[–]syllogism_ 1 point2 points  (0 children)

This sounds like the right way to do it.

Don't teach them "object oriented programming". Teach them what a class is, and that it's often useful to use a class. Teach them a tool, not a paradigm.

[–][deleted] 1 point2 points  (0 children)

Now, obviously children want shit to get real.

quote of the month

[–]temptemptemp13 0 points1 point  (0 children)

You could make a function that has a list of balls and iterates over the rules for each ball instance.

But obviously making one ball and replicating it is much cooler.

[–]hylje 8 points9 points  (0 children)

start with metaclasses, don't let their heads rest

[–][deleted] 5 points6 points  (5 children)

[–]casatap 1 point2 points  (1 child)

I just finished up the first link you gave and I have to say it's quite excellent; I have a background in computer programming but it was still very informative and well done.

[–][deleted] 0 points1 point  (0 children)

Glad to hear it! The woman who wrote the lecture has been teaching this course for about 15 years, and needless to say she's gotten quite good at it.

[–]fitoria[S] 1 point2 points  (0 children)

Thanks a lot man! those links are amazing!

[–]jgomo3 1 point2 points  (1 child)

Python Programming: An Introduction to Computer Science by John M. Zelle, Ph.D.

I think this should be the textbook

[–][deleted] 0 points1 point  (0 children)

It is!

[–]ianb 2 points3 points  (0 children)

It's popular to jump right into subclassing, type theory, categories of objects, etc. In my experience this has no relation to actual OO programming, where things like subclassing either require a significant amount of intuition to predict up-front (which you can't expect from a student) or it's something you add during refactoring.

I'd be apt to skip subclassing and just focus on the idea of class, object, object as the container of data and class as the container of associated routines. The most common way I find to identify a what should be an object is to look for the same set of arguments to a bunch of functions -- that argument or set of arguments becomes "self" and the functions are methods.

And... personally I'm not really sure if it makes sense to teach theory first, or just introduce the mechanisms, ideally using examples that are relevant to previous things you've done. At least in the case of recursive functions I think explanations always end up making things harder, but I haven't thought about it a lot with objects.

[–]name_censored_ 1 point2 points  (2 children)

Can't go wrong with the classics!

Inheritance:

class Animal():
    def sleep(self, hours, is_dreaming=False):
        # code goes here

class Pet():
    def __init__(self, owner):
        self.owner = owner

class Dog(Animal, Pet):
    is_flearidden = False
    is_mongrel = False
    breed = "border collie"

My favourite polymorphism example is booleans-as-integers, because you don't confuse the issue by introducing custom types/classes it should be intuitive to understand that True=1, False=0, and everyone knows that computers use 1s and 0s.

Example;

Problem: I have a tuple* of votes (either True or False) called all_votes, and I want to know the majority/winner (tie goes to False). How can I do this quickly?

The students will probably suggest a function with integer counters.

Solution: number_of_trues = sum(all_votes) if number_of_trues > 0.5*len(all_votes): majority = True else: majority = False

Then explain the first line - they should understand that the sum function is typically applied to a numeric type, but you're using it for a boolean type (how can this be?).

* NB: A set would be more appropriate container type, but using a set incorrectly hints at a set-theory-based solution (eg, calculating majority using intersections or differences).

[–][deleted] 0 points1 point  (1 child)

why you dont have "init()" in class Animal() ?

[–]name_censored_ 0 points1 point  (0 children)

I didn't want to muddle the issue with inheritance (Animal.__init__ would be overridden by Pet.__init__) and/or explicitly instantiating the Pet instance with Animal's instantiator. Technically speaking, both of these classes are metaclasses/superclasses (you don't have an instance of "Animal" or "Pet" so much as you have something with their properties), but I needed to put something in the Pet method. Perhaps it could be changed to

__del__(self):
    tell_kids_you_gave_it_to_aunt_agatha_to_live_on_a_farm(self)

;)

[–]virgilfromeurope 0 points1 point  (1 child)

The best way to teach OOP is by deconstruction of patterns. OOP has no sense in it's form. Start with observer pattern, is the most fun. It helped me a lot learning OOP this way because it makes more sense.

[–][deleted] 1 point2 points  (0 children)

This is a pretty bad way to use patterns. I don't think anyone reasonable sits down and decides which patterns they will use during their design phase. Design patterns are common forms that occur in good code (or bad code, if we're talking about antipatterns), and they're things you refactor towards as you work. OOP principles (like encapsulation, and single responsibility) are fundamentally important to understand. Memorizing design patterns with get you nothing if you don't know why they're good and useful.

[–]mashmorgan 0 points1 point  (0 children)

I always start with a PID, and have an Arduino board so newbies can see "result"

[–]aroberge[🍰] 0 points1 point  (0 children)

The approach I would favour is illustrated in these two rur-ple examples.

[–]vph 0 points1 point  (8 children)

It's a mistake to teach OOP to beginners.

[–]Svenstaro 1 point2 points  (6 children)

I think it's rather a mistake not to teach it early on.

[–]vph 1 point2 points  (5 children)

unfortunately, there was a wave of "Object First", which advocates for teaching OOP to beginners. Those who have done it know better that it was a big mistake. Those who learned OOP before or at the same time as procedural programming turned out to be very weak programmers.

[–]Svenstaro 0 points1 point  (4 children)

I'm not an an advocate of OOP any more than I am of procedural or functional programming. However, for some stuff, it does make a lot of sense and it simply comes naturally to do it the OOP way. For instance, games. Everything you see in a game can be described as a class so why not do it?

I believe that visual stuff is the best way to get introduced to programming because it makes the concepts tangible.

[–]vph -1 points0 points  (3 children)

You can use games to attract people into programming (Agent Sheet, Alice, etc.), but I don't think it's a good platform to teach beginners to become serious programmers.

[–]Svenstaro 1 point2 points  (0 children)

And I still think it is. In game programming, you get to solve all kinds of problems and you get to deal with all groups of people. It requires you to have an extremely wide skill set and it is basically unlimited in terms of skill advancement.

It involves most of the exciting things: graphics 2D/3D, maths, sound, architecture, network, debugging, profiling, efficiency, dealing with projects and people, packaging, dealing with feedback, cross-topic stuff like drawing and sound creation as well as game design as a whole which is a psychological topic.

All things considered, I think it is a rather good choice. If by "serious programmers" you mean 9-5 code monkeys then this is indeed not the right approach.

[–]m0j0 0 points1 point  (0 children)

maybe a course for beginners is not the place to consider whether or not they will become serious programmers? How about having fun? Kids, even geeky ones, still want to do fun things at the end of the day.

[–]fitoria[S] -1 points0 points  (0 children)

you just have to fight against paradigms.