The medium of thought: @Scratch is bad for learning Programming and Computational Thinking? #coding #edtech #education

…Maybe. It depends.

I’m increasingly frustrated by the various groups and media who seemingly want to shoot-down all the positive work we do with teaching good programming practice in textual programming languages. While tens of thousands of educators have been pushing ahead with the 21st century, teaching children not only to program, but more importantly how to think, independently … others want to drag them back. The FaceGoogMicroAppleBooks of this world want easily-controlled, cheap, consuming do-ers. Not thinkers. Not … rivals.

I realised today that I can put it quite plainly, though I’ve never dared to do so before. I love Scratch, Scratch is fun; but there’s always been a major problem with it, one we don’t really talk about:

Scratch (for instance; you could pick others here) encourages people to program badly, to not think about what they’re doing, and to learn bad habits of coding that actively damage their ability to solve problems or write code.

There, I’ve written it. I’ve said this to many people before, those that understand the nuance behind it, but never in writing or publically (I think).

In my experience, that’s part of why it’s great: in the hands of a teacher who deploys it knowingly, the language avoids every piece of good practice. There’s no planning, there’s no debugging, there’s no thinking – you just get straight into creating. When your target outcome is to get children creating, or to get them interested in computing, or to get them to believe in their ability to control robots, computers, machines … “learning computational thinking” often isn’t the priority.

And when a teacher wants to use it as a medium for talking about CT concepts – e.g. predicting what a script will do – it’s quick and easy to have that conversation. Scratch is not used in a vacuum: it’s used in a classroom, by teachers, who are experts in what they do.

The medium of thought

Q: Why do we have textual programming languages?

A: Because they’re easier to interpet, speak, read, and write than punched cards…

But why do we still use textual programming languages today, for nearly everything (by “nearly”, I mean “something like 99.99999% of all code written by humans”)?

For similar reasons to why we still write books. Why we have news websites, 10 years after YouTube. Why the web … is text (by volume of content, not volume of disk-space). Text is not perfect, text cannot do everything; a picture can paint a thousand words, but text lets the painter decide what every individual word will be, whereas the picture does not.

Text is still the best (among many good candidates) general medium for human beings to express themselves, to communicate, and to begin to understand one another. For as long as human beings are writing the programs, programs will be written in text.

Who needs understanding anyway?

But … working with both primary and secondary children, and with adults, time and time again I’ve seen the same failure of learners to do CT with Scratch, unless given considerable amounts of scaffolding / prompting / interrogation. The language facilitates this; is it a surprise that learners then do so, avoiding unnecessary work and thinking?

e.g. I’ve stopped being surprised when Y7 or Y8 children say they’ve “done Scratch”, and refuse to do worksheets because “I know it already” … but are incapable of reading – let alone explaining! – a 4-line Scratch block script to me, and can’t remember how they achieved any of the programs they remember writing previously. Without their worksheets (e.g. the great Scratch Cards), they’re lost and hopeless. This is not rare.

Personally, I don’t think any of this is a problem. In my opinion this fits the learners’ journey, and slots in neatly to the schemes of work we have at primary vs secondary: start with visual languages (which may be completely useless for learning programming and CT in most cases) for things they’re good at, dabble in CT if appropriate for your classes, later move into textual languages, and gradually re-think how they engage with “problems” and “solving things”.

But because I’m comfortable with it, I don’t talk about it. And it seems that’s created a vacuum for well-intentioned but damaging ideas and publicity to creep in. We can throw away the textual languages, polish the “don’t think, do” replacements until they bear fancy portfolio pieces – but we’re really saying “don’t worry, you’ll be told what to think”.

Down that route we’re not equipping learners, we’re making them into creators (which is great, an improvement on what went before), but tied into sandboxes they can never escape. Today, and in recent years, we’ve been aiming much higher and getting there – we’ve taught Computational Thinking, taught advanced programming, taught how to solve problems in the real world as much as the digital. But if you throw that away, you lose more than just some keyboard-typing. There won’t be reasoning, there won’t be CT, children will have portfolios of beautiful 3D experiences they’ve created – but they’ll have no idea how they did it. And soon they’ll find they aren’t creators, they’re merely assemblers, re-making over and over again the same constructs that were decided for them before they even started…

Leave a Reply