The past two years I have used Adafruit’s Circuit Playground Express in my CS1 classes. The students really enjoy working with them, and while there were a few hiccups this year (more about that in another post), I felt like it was time well spent and the students learn quite a bit.
The CPX is this really nifty all-in-one device that runs Circuitpython. It has built in touch sensors, buttons, a switch, speaker, temperature sensor, accelerometer, infrared sender/receiver, and LED lights called Neopixels. Check out the link above for more information, but needless to say it does a LOT of cool stuff. In addition to Circuitpython, it can also run Microsoft’s MakeCode. I really like the interface for MakeCode, and actually had the students play around on the website for a bit. I used it as an opportunity to talk about “block-based” languages. Keep in mind, this came at the end of the year, so the students had about 6 months of experience with Python.
I asked them to give list some advantages to the block-based language. All of the expected ones were there:
- No concern for syntax errors
- No need to remember commands or keywords
- It was easy to see what was or wasn’t allowed because of the shape of the blocks
- No need to go looking through documentation to find an available list of functions, just search through the pretty colored categories.
I then asked for any disadvantages:
- Once you were familiar with the keywords or functions, it became tedious to use the drag-and-drop interface
- They didn’t think they could add their own custom functions (which I showed them afterwards could be done pretty easily in the “advanced” section)
- In line with the previous, they felt like the block-based coding was more restricted than text-based, but they could not articulate why they thought that
- Removing or changing blocks is tedious; if there is a very small change necessary you often have to drag apart multiple groupings of blocks in order to make the change.
These issues were very similar to the complaints that my OnRamps classes had about Scratch, so no real surprises here.
I then asked which style of language they preferred. They unanimously agreed that while MakeCode might be easier for a beginner, they still preferred Python. This is understandable: they just spent 6 months learning a text-based language, of course they’re going to prefer what they are familiar with!
(I did show them how MakeCode would convert very nicely to Javascript. BUT since they aren’t familiar with Javascript, they did not see the advantage that brings. So our discussion focused on the block-based nature of MakeCode. I’m not comparing Python to MakeCode, but instead block-based to text-based.)
Finally, I asked them to put on their beginner hats for a moment and rewind time. I told them to go back to their August 2018 self, who doesn’t know any programming. Would that self have preferred the block-based language, even if just for a month to learn? Every one of them said “no”. They gave some interesting reasons for this (I am elaborating on their responses a bit, none of these are word for word what they said):
- Starting with something more “difficult” when you don’t know any better is easier than starting easy and working your way to difficult.
- My analogy for this one: Pretend you have two dumbells (weights), one is 5 lbs and one is 30 lbs. Which will seem more difficult:
- Pick up the 30 lb weight, or
- First pick up the 5 lb, THEN pick up the 30 lb
- They all said the 2nd one would be more difficult since you will have a lighter weight to compare to the heavy one, whereas in the first instance, you won’t know any better and just kind of go with it.
- By starting with Python (or text-based programming) they were just under the impression that this is programming. Without an “easier” thing to compare to, they just accepted it and struggled but weren’t complaining about wanting to do things the easier way.
- My analogy for this one: Pretend you have two dumbells (weights), one is 5 lbs and one is 30 lbs. Which will seem more difficult:
- They felt a greater sense of accomplishment using Python (text-based) than using MakeCode (block-based)
- This one is interesting, but not terribly unexpected. Block-based languages seem like anyone can do them. While this is great from a recruitment perspective, it may have an unexpected downside. Think about it, if EVERYONE can do it, then when you have difficulty you must just not be good enough!
- I would argue that programming, whether it be block-based or text-based, is difficult and requires a lot of hard work and thinking.
- However, when the student struggles with Python (or another text-based language), they are fine with that, because it is “hard” (and looks hard). When they finally get the program working, they feel real pride for having overcome the challenge.
- When that same student struggles with a block-based language (Scratch/MakeCode) they feel like they can’t do something that everyone else can do. When they finally get the program working, they don’t feel the same pride because they expected for it to work the first time!
- “Real” programmers use text-based languages.
- Not much to say here. I challenge you to find anyone in industry (not academia) using block-based languages for their daily jobs. In fact, if you find them I would be curious to know what they’re using and why. I’m always open to new ideas!
I took a vote from my classes asking if I should start CS1 next year with a block-based language instead of Python. Not a single student said they thought I should start with block-based programming. Now there is some selection bias here, I know. The students who might benefit most from starting with block-based dropped the class at the semester. This wasn’t a large number, but there were a few. However, I’m not convinced that those students would have stuck it out if I had used something like Scratch or MakeCode either. The students who dropped didn’t drop because of low grades (very few were failing). They dropped because they weren’t enjoying the class. I could probably argue that they weren’t enjoying it because it is “hard” and they didn’t want to exert the mental effort necessary to understand what we were doing, and if I were to use Scratch/MakeCode, it would be “easier” and would require less up front effort. I think they would eventually hit a wall though and not want to continue. Maybe it’s better they find out sooner rather than later that they don’t enjoy the subject?
While their feedback validated my thinking and some of my reasons for choosing Python for my CS1 classes, I can’t help but wonder what differences starting with Scratch would have on the class dynamic. Students would be able to get up and running with neat graphical applications much faster. They would be able to more easily share their products with family and friends. They can make cool (though probably very basic) games and applications very quickly. I wonder if that is the goal though. I mean, is computer science about instant gratification? In order to make any programs of substance, you have to have a lot of perseverance and persistence. Debugging code is a pretty useful skill that is mostly eschewed by block-based languages, if nothing else because you can’t really get syntax errors. Finally, Scratch and MakeCode often fail to reinforce the sequence of program execution; everything (seemingly) happens simultaneously. Async, threading, and multiprocessing are getting more and more common, but I can’t imagine starting off my programming journey without understanding flow of execution!
I do see how separating logic from syntax might be nice, but I think you lose something. I wonder how effective an English class would be if they used “block-based” languages. Where students could essentially drag and drop sentence stems together and just fill in a few blanks. While this strategy might be terrific for a younger audience, at some point (high school at the latest, I think) the student needs to be able to form their own thoughts into their own sentences into their own paragraphs. They need to remember how to spell some words. They need to remember some grammar rules (yes, I know they can always Google them when in doubt, but you have to remember some basics for sure!)
I think the same holds true for programming.