Fair warning: This is going to be a long one, with some musings about how to approach the idea of introducing objects. It’s based around my personal experiences teaching myself Processing and observations in the wider Processiverse (Yes, I’m coining that term). As for a desired outcome, I’m not sure. Just initiating a discussion would be a good start.
I’ll also frame everything by saying that I’m thinking more about artists and designers venturing into creative coding, as opposed to people who are on a CS track. I’m thinking mainly in terms of visual output and not data manipulation.
(Also, I’m not sure about what category this post fits in best. Mods, do your thing.)
///
I’ve forever been intrigued by object-oriented programming, for three main reasons:
- It’s so darn powerful and unlocks a whole new level in my coding capabilities.
- It’s this massive complexity spike which sneaks up on you after you’ve put down some coding foundations. The spike feels completely disproportional to what people learn up to that point and from my own observations can be a real reason why one might completely lose interest in pursuing creative coding any further.
- I’ve yet to find an educational resource which manages to effectively prime a pupils brain to voluntarily put in effort to learn more about objects.
My thoughts revolve around points 2 and 3.
As a representative example I’m using the Objects tutorial from the Processing website. Let me state that far more than half of the things I know about and can do with code is thanks to Dan. But I’m convinced this tutorial is still missing a vital point.
It teaches you all the correct things about the concept behind a class/object, it’s building blocks and how you might transfer your previous code into object form.
But it fails to answer the question “Why put in the effort?”.
Put yourself into the shoes of a beginner/intermediate coder.
They have understood variables, basic datatypes, fought with arrays, created a custom function, steered the flow within a sketch, drawn smiley faces onto the screen.
And now the instructor tells them that objects are this powerful thing that will unlock their next level. And then a ton of foreign concepts rain down onto this pupil. “Blueprint”? “Cookie cutter”? Class? Object? Constructor? Fields? Functions are now methods? set? get? Even distant whispers of Inheritance and Polymorphism.
To the pupil it feels like they have to put in effort to write more code, FOR THE SKETCH TO DO THE EXACT SAME THING afterwards.
So why write more complex lines of code with no obvious advantage to it? That Objects tutorial, as most others, are guilty of this. They demand that the pupil trusts that the upfront effort will produce a payout sometime down the line.
I’m here to propose that we can incorporate part of that payout right at the start of an OOP jounrney.
Let’s take this baseline sketch from the tutorial:
color c = color(0);
float x = 0;
float y = 100;
float speed = 1;
void setup() {
size(200,200);
}
void draw() {
background(255);
move();
display();
}
void move() {
x = x + speed;
if (x > width) {
x = 0;
}
}
void display() {
fill(c);
rect(x,y,30,10);
}
Now instead of the tutor starting to introduce the concept of an object and refactoring the code, he gives the following task: “Rewrite the sketch to have two cars move on screen”.
After some thinking and code wrestling, the pupil will come up with this:
// car1 variables
color c1 = color(0);
float x1 = 0;
float y1 = 100;
float speed1 = 1;
// car2 variables
color c2 = color(125);
float x2 = 0;
float y2 = 50;
float speed2 = 1.5;
void setup() {
size(200,200);
}
void draw() {
background(255);
// draw car1
move1();
display1();
// draw car2
move2();
display2();
}
void move1() {
x1 = x1 + speed1;
if (x1 > width) {
x1 = 0;
}
}
void move2() {
x2 = x2 + speed2;
if (x2 > width) {
x2 = 0;
}
}
void display1() {
fill(c1);
rect(x1,y1,30,10);
}
void display2() {
fill(c2);
rect(x2,y2,30,10);
}
This is not a good solution, but a solution the pupil will be able to come up with and understand based on their coding level.
“Right”, says the tutor, “now make it three cars”. The pupil, smart as they are, have already identified the pattern. So they copy all relevant parts and add a ‘3’ into all the correct places. The sketch is becoming slightly unwieldy, but it works.
“Neat” goes the tutor ”and in the next step…”, “we draw four cars!” interrupts the pupil giddily.
“No”, says the tutor. “Make it one thousand cars”.
This is the moment the pupil falls off their chair, because it’s fully apparent that this is a ridiculous ask. Their way of thinking about code structure has reached an obvious limit and being a typical pupil, they will beg for a solution that requires way less effort to implement.
Now the tutor goes: “What if I told you, there’s a way you can build your code, in which you can easily change the number of the cars, to anything you want? It just requires some setup first. Let me show you".
The tutor presents an OOP sketch with a “numCars” variable set to 3. Then changes the variable to 1000. Then to 10000. And it just works, only by changing one single value. The best part: The whole sketch is way shorter than what the pupil had in mind as a solution.
This is also the point where the Object tutorial enters that conversation and introduces all the details about this still complex, but obviously mighty concept of an object. With the main difference, that the pupil will now be operating with a clear proof on the power of adding that initial complexity.
///
Yeah, that’s it. Sorry for making it ramble-y. Looking forward to any feedback and counters.
