legozilla-via-flickr
Training and Development

My life as a tech teacher, part 8: A clash of logic

Sometimes programmers write code that should work, but doesn't. Actually this happens all the time. At some point or other we've all written logical, well-structured code that somehow doesn't do what it logically should.

I have a friend whose husband is a programmer. Occasionally she'll look over his shoulder when he's particularly frustrated about a non-functioning block of code, before casually announcing, "I think you've missed a semi-colon." She knows nothing else about programming, but often she's correct – much to his annoyance.

But sometimes the issue is more fundamental. It's a clash of logic between the programmer and the language being used. All programming languages were written by someone. Most of them were designed to be logical and clear to understand. However, one person's logic isn't necessarily the same as another's.

We discovered this with Scratch. This week I asked the children to create a game of sorts. It had to involve a human-controlled sprite that would interact with another sprite, or perhaps the background, and react in some way. For example, perhaps a dog would chase a cat and shout 'woof!' when it caught it. Or maybe a witch would fly towards the sun and shout 'Ouch!' when she reached it.

tt8-if-condition-1

Several of the children worked out how to do this, then asked me why it didn't work. Looking at their code, I didn't know either. Their logic appeared sound. As you can see in the first screenshot for this article, they were checking for an interaction with another sprite. If their 'if' condition was met then the appropriate action should have been taken. But it wasn't.

After a while I worked out what was happening. We were all assuming that Scratch would run its 'if' conditions independently as parallel processes. That's true of some types of code, but it doesn't work with 'if' statements. So instead of the code block constantly checking whether two items were interacting, it was just sitting there waiting to be called.

There are good logical reasons for this: for example, why waste CPU cycles checking for a condition that can't be met? But that logic was different to my logic and that of the children. Still, we solved it. Attaching the 'if' condition to an event, such as a key-press and sprite movement, made the code work as we had expected, as the second screenshot shows.

tt8-if-condition-2

I explained to the class that programmers always have to work within the constraints of the development environment, and that sometimes those constraints can be frustrating. But that's the only minor hurdle we've experienced with Scratch, which has provided a great starting point for this group of tomorrow's programmers.

That was the last lesson of term before the Easter break. Like all teachers, I'm looking forward to doing very little for two weeks... well, apart from the day job. I've been asked if I can come back next term and do some more tech teaching. I'd like to. I've laid the foundations but there's more I can teach these children before sending them off to online programming courses, where their programming skills will eventually far exceed my own.

PREVIOUS ARTICLE

« Why European nearshoring is definitely an option now

NEXT ARTICLE

Are wearable tech startups just looking for problems? »
author_image
Alex Cruickshank

Alex Cruickshank has been writing about technology and business since 1994. He has lived in various far-flung places around the world and is now based in Berlin.  

  • Mail

Poll

Do you think your smartphone is making you a workaholic?