Not everyone likes Scratch — the block-oriented programming language that MIT developed to help kids program. While dyed-in-the-wool programmers probably find it limiting, it can be an effective way to teach basic programming to newcomers and there are some people who enjoy the graphical style of programming.
The latest Raspbian release (the operating system image for Raspberry Pi) has a new and improved version of Scratch for those who want to use it on the Pi. According to the Raspberry Pi blog, the new version is up to ten times faster than previous versions and also includes an improved method for Scratch programs to access the board’s general purpose I/O and other I/O devices.
As an example of the new speed up, a Pac Man demo that could only manage one frame per second on a Raspberry Pi B, now clocks in at 12-15 frames per second and can exceed 30 fps on a Raspberry Pi 2. In addition to some additional I/O boards, the new Scratch can also access the camera, the board’s IP address, and the date and time.
Granted, Scratch isn’t for everyone and that’s ok. But if you do want to use Scratch (or teach with it) the extra speed and features will be a welcome addition. We’ve seen other versions of Scratch with enhanced I/O capability. There’s even been sensors built specifically for Scratch setups. Still, having support for the Raspberry Pi will be handy, especially in the classroom. If you don’t want to use a Pi, there’s always versions of Scratch for the Arduino, too.
My daughter was able to rapidly move from Scratch to Java Script and Python therefore I believe that it is a very good first introduction to programming and the graphical nature of Scratch teaches structure and logic over syntax, which is vital if kids are to move on to other languages. One thing to be careful of, make sure you do show the student how the structures in text based coding systems match the block structures in Scratch, then they will hit the ground running.
What is her age, and did you use any material to get her started?
She started coding around 7 or 8, and we began before that with a solid foundation in mathematics and literacy. This is were all the naive feel-good teaching programs go wrong, you can’t teach programming to the innumerate, you also need to take into account the behavioural differences between boys and girls. There are individual attention span and motivational issues that your teaching needs to take into account. Giving the student a strong appreciation of the fact that knowledge is power and that maths underlies every rational pursuit is the key. How you do this depends on the specific personality and background of the child. We live in a science rich and ritual free household so it was not as hard as it may be for others. The “It is a machine so there is no point getting frustrated with it.” lesson is an important one, along with the point that machines don’t get poetry either, so you need to be exact when instructing and controlling them.
All of our systems are Linux based and our software is FOSS. We only spend money on hardware and use a trickle down process to hand older machines to the younger kids as we upgrade machines for the adults and older students. This has a side benefit that the older ones know the territory when helping out a younger sibling who now has their old system.
When starting out recipes and flow diagrams help with the understanding of sequencing and process flow, you don’t need a computer for that, games using pen and paper, chalk on concrete, or just a stick in the sand are just as effective, as they are for geometry.
So in a nutshell, if you don’t get the fundamentals right first there is no point teaching how to code, however coding skills will help to re-enforce those fundamental skills once they are established.
And in a single variable the answer is, “Time invested in guiding the child”. Which is why we home school. :-)
I am co-author of a Scratch-based book for Italian primary school (http://deagostiniscuola.deascuola.it/primaria?layout=book&ref=41&book=11847) and I can confirm that Scratch works.
We had fun writing that book (I even managed to put in a couple of minimalist graphic adventures) and Scratch seems to be very effective in helping children develop logical thinking. Its main drawback is the dependency on Adobe Flash, which is pretty annoying (especially if you are using Linux).
Here is a tip: do not rely too much on traditional logic control structures when writing (or making people write) Scratch code. Do not treat it as a Pascal variant. Scratch being a multitasking environment, It is a lot more effective (and often clearer) to use messages instead; Scratch messages are more powerful than they first appear. Dynamic programming can look strange to people only used to ’80s coding methods, but children pick it up easily (e.g. send a message = shout something for all to hear).
Is that really very different from the interrupt routines people have been using in assembly language since the 8080 was released in 1974? Or did you mean people who “programmed” in Basic etc.?
This Scratch is (an improved version of) the original Squeak Smalltalk one. A lot of people didn’t like the dependency on Flash
Actually, I see no relations between interrupts and asyncronous message passing in a multitasking environment (apart from the obvious fact that interrupts could be used by the multitasking scheduler, but that is an implementation detail).
Scrath message passing is more akin to using queues for interprocess communication (but a lot simpler and with some limitations). Of course I don’t say that to the children :-)
The Earth-Moon synchronization in this “orrery without trigonometry”) is a trivial example, but you can do pretty interesting things with Scratch messages:
https://scratch.mit.edu/projects/62467626/
There is no one-fits-all programming way: when you program in C, think structured; when you program in Java, think OO; when you program in Scratch, think messages (etc.).
I think that the most important part of this news is that at least part of the Scratch community thinks it’s worth sticking with Squeak/Smalltalk, rather than using Javascript as an implementation language.
After all, Smalltalk was intended as a teaching etc. language, and I think it’s reasonable for somebody who finds (s)he can’t express something in Scratch to use Smalltalk as the next step. In the unlikely event that Smalltalk’s inadequate, that’s the time to consider a “full-fat” C-type language.
Is Scratch implemented in Squeak/Smalltalk or Javascript?
Nevermind! I found the answer on scratch site.
“Scratch is written in Squeak, an open-source implementation of the Smalltalk-80 language. “
Scratch 1.4 is written in Squeak, but I believe that the “official” version is now Scratch 2.0 which has been recoded in Javascript. What’s more MIT appear to want you to write extensions in Javascript, and host them on Github.
So in effect we’re seeing Scratch being forked, and my sympathies are definitely with the Pi tine on this since whatever Javascript’s strengths being friendly to a beginner isn’t one of them.
The reason I started looking at this was a suggestion elsewhere that if somebody made a cuddly toy with an internal battery box and servos, a kid could “accidentally” discover that the family RPi fitted inside and that (s)he could make it /do/ things when programmed up in Scratch. Then I discovered that mainline Scratch would probably want a permanent connection to Github, and had a vision of society collapsing when a power cut meant that the parents couldn’t watch TV and the kids couldn’t play with their toys. — MarkMLl
No, it’s much worse. The current MIT release of Scratch is written in (gasp) Flash. The version include with the Pi is developed from the original Squeak version, with lots of work to speed it up including development of an ARM dynamic translator Cog VM. It does not need a network connection. It can run on any machine that can run Squeak – which is pretty much any computer.