Programming in blocks lets far more people code — but not like software engineers: Response to the Ofsted Report
June 20, 2022 at 7:00 am 20 comments
A May 2022 report from the UK government Research Review Series: Computing makes some strong claims about block-based programming that I think are misleading. The report is summarizing studies from the computing education research literature. Here’s the paragraph that I’m critiquing:
Block-based programming languages can be useful in teaching programming, as they reduce the need to memorise syntax and are easier to use. However, these languages can encourage pupils to develop certain programming habits that are not always helpful. For example, small-scale research from 2011 highlighted 2 habits that ‘are at odds with the accepted practice of computer science’ (footnote). The first is that these languages encourage a bottom-up approach to programming, which focuses on the blocks of the language and not wider algorithm design. The second is that they may lead to a fine-grained approach to programming that does not use accepted programming constructs; for example, pupils avoiding ‘the use of the most important structures: conditional execution and bounded loops’. This is problematic for pupils in the early stages of learning to program, as they may carry these habits across to other programming languages.
I completely agree with the first sentence — there are benefits to using block-based programming in terms of reducing the need to memorize syntax and increasing usability. There is also evidence that secondary school students learn computing better in block-based programming than in text-based programming (see blog post). Blanchard, Gardner-McCune, and Anthony found (a Best Paper awardee from SIGCSE 2020) that university students learned better when they used both blocks and text than when they used blocks alone.
The two critiques of block-based programming in the paragraph are:
- “These languages encourage a bottom-up approach to programming, which focuses on the blocks of the language and not wider algorithm design.”
- “They may lead to a fine-grained approach to programming that does not use accepted programming constructs…conditional execution and bounded loops.”
Key Point #1: Block-based programming doesn’t cause either of those critiques. What about programming with blocks rather than text could cause either of these to be true?
I’m programming a lot in Snap! these days for two new introductory computing courses I’m developing at the University of Michigan. I’ve been enjoying the experience. I don’t think that either of these critiques are true about my code or that of the students helping me develop the courses. I regularly do top-down programming where I define high-level custom blocks, as I design my program overall. Not only do I use conditional execution and bounded loops regularly, but Snap allows me to create new kinds of control structures, which has been a terrific help as I create block-based versions of our Teaspoon languages. My experience is only evidence that those two statements need not be true, just because the language is block-based.
I completely believe that the studies being cited in this research report saw and accurately describe exactly these points — that students worked bottom-up and that they rarely used conditioned execution and bounded loops. I’m not questioning the studies. I’m questioning the inference. I don’t believe at all that those are caused by block-based languages.
Key Point #2: Block-Based Programming is Scaffolding, but not Instant Expertise. For those not familiar, here are two education research terms that will be useful in making my argument.
- Scaffolding is the support provided by a learner to enable them to achieve some task or process which they might not be able to achieve without that support. A kid can’t hop a fence by themselves, but they can with a boost — that’s a kind of scaffolding. Block-based programming languages are a kind of scaffolding (and here’s a nice paper from Weintrop and Wilensky describing how it is scaffolding — thanks to Ben Shapiro for pointing it out).
- The Zone of Proximal Development (ZPD) describes the difference between what a student can do on their own (one edge of the ZPD) and what they might be able to do with the support of a teacher or scaffolding (the far edge of the ZPD). Maybe you can’t code a linked list traversal on your own, but if I give you the pseudocode or give you a lecture on how to do it, then you can. But the far edge of ZPD is unlikely to be that you’re a data structure expert.
Let’s call the task that students were facing in the studies reviewed in the report: “Building a program using good design and with conditioned execution.” If we asked students to achieve this task in a text-based language, we would be asking them to perform the task without scaffolding. Here’s what I would expect:
- Fewer students would complete the task. Not everyone can achieve the goal without scaffolding.
- Those students who do complete the task likely already have a strong background in math or computing. They are probably more likely to use good design and to use conditioned execution. The average performance in the text-based condition would be higher than in the block-based condition — simply because you’ve filtered out everyone who doesn’t have the prior background..
Fewer people succeed. More people drop-out. Pretty common CS Ed result. If you just compare performance text vs. blocks, text looks better. For a full picture, you also have to look at who got left out.
So let’s go back to the actual studies. Why didn’t we see good design in students’ block-based programs? Because the far edge of the ZPD is not necessarily expert practice. Without scaffolding (block-based programming languages), many students are not able to succeed at all. Giving them the scaffolding doesn’t make them experts. The scaffolding can take them as far as the ZPD allows. It may take more learning experiences before we can get to good design and conditioned execution — if that even makes sense.
Key Point #3: Good software engineering practice is the wrong goal. Is “building a program using good design and with conditioned execution” really the task that students were engaging in? Is that what we want student to succeed at? Not everyone who learns to program is going to be a software engineer. (See the work I cite often on “alternative endpoints.”) Using good software engineering practices as the measure of success doesn’t make sense, as Ben Shapiro wrote about these kinds of studies several years ago on Twitter (see his commentary here, shared with his permission). A much more diverse audience of students are using block-based programming than ever used text-based programming. They are going to solve different problems for different purposes in different ways (a point I made in this blog post several years ago). Few US teachers in K-12 are taught how to teach good software engineering practice — that’s simply not their goal (a point that Aman Yadav made to me when discussing this post). We know from many empirical studies that most Scratch programs are telling a story. Why would you need algorithmic design and conditioned execution for that task? They’re not doing complicated coding, but the little bit of coding that they’re using is powerful and is engaging for students — and relatively few students are getting that. I’m far more concerned about the inequitable access to computing education than I am about whether students are becoming good software engineers.
Summary: It’s inaccurate to suggest that block-based programming causes bad programming habits. Block-based programming makes programming far more accessible than it ever has been before. Of course, we’re not going to see expert practice as used in text-based languages for traditional tasks. These are diverse novices using a different kind of notation for novel tasks. Let’s encourage the learning and engagement appropriate for each student.
Entry filed under: Uncategorized. Tags: block-based languages, blocks-based languages, computing education research.
20 Comments Add your own
Leave a comment
Trackback this post | Subscribe to the comments via RSS Feed
Computing Ed Research - Guzdial's Take 
1.
jsheldon | June 20, 2022 at 7:51 am
Thank you Mark. This is a great post that we need as we work to broaden participation in computing.
2.
Dennis Bouvier | June 20, 2022 at 11:13 am
All too often computing education research publications provide an incomplete picture of the context of studies. The research describes the tools/languages and the particular ‘thing’ being observed. The description of the curriculum is not part of the published description, but it is a significant part of the context. (It would be difficult to provide a complete description of the curriculum.) However, even if the teachers are accomplished software engineers, do we know if they teach what is ‘good software engineering practice’ to their students? We don’t know. Is it likely they did? Probably not. Good software engineering practice is likely not a learning goal (learning goals are rarely part of a publication). Why hunt for unicorns?
3.
rademi | June 20, 2022 at 2:38 pm
I see a strong parallel here with the technical vocabulary requirements that we encounter in other coursework.
Or, on the flip side, with the difficulties we have in picking up useful techniques for using programs which have a long history and extensive features (excel, vi/emacs, TeX or word, blender, etc.).
Generally speaking, … there’s some core elements of any system where we can pick up skill quickly, but our planning is limited by our experience and implementation is limited by our familiarity.
4.
mlmiller (@mlmiller) | June 20, 2022 at 3:07 pm
I would add an additional critique that is implicit in the discussion: all block-based languages are not equal. In particular, Scratch (and probably several others) lack the ability to define a function that returns a value except by modifying a global variable (definitely at odds with best practice in software engineering). Snap!, by contrast, provides that capability as well as other well-accepted practices such as higher order functions. As a separate matter, if memory serves, there is some evidence that students who learn a block-based language first later show greater success in a text-based language later, even those who express the opinion that the block-based language was “too baby-fied” for them (as noted in some of the “related” topics shown. We will need to be more precise in our claims as we do these sorts of experiments. Over-broad claims in the early days about what did or did not work with Logo, for example, harmed funding at a time when we were just scratching the surface of what these new technologies could mean for education (including education outside of software engineering job training).
5.
garystager | June 20, 2022 at 7:27 pm
I agree with Alan Kay that to the extent that we wish to declare “Logo failed,” it failed because teachers did not understand the mathematics their students were engaged in.
You are indeed correct about Scratch. The biggest problem I observe is the number of educators proudly announcing “We do a little Scratch.” Not only does Scratch make serious compromises limiting its computational power, but it provides the illusion that computing is doable in an hour per year – actually Code.Org decided that was too ambitious and reduced programming to crappy puzzles.
Fluency eludes far too many kids and their teachers.
6.
garystager | June 20, 2022 at 7:24 pm
Thanks Mark,
This is excellent and useful. I will share it.
I am more than a bit bemused by governments making proclamations about such topics. Not only does such meddling seem petty, but it reminds me of Emily Literal on television violins or Strom Thurmond urging a witness to speak into the machine.
7.
garystager | June 20, 2022 at 7:24 pm
Mark,
I would also like to learn more about what you’re doing in Snap!
8.
garystager | June 20, 2022 at 7:33 pm
As for the dual-modality instruction study, couldn’t this just be evidence of what Marvin Minsky (and common sense) tell us, “You don’t understand something unless you understand it several ways?”
Using different teaching strategies is hardly a novel discovery.
9.
rademi | June 20, 2022 at 9:11 pm
In and of itself, you are correct: using different teaching strategies is not novel.
Finding new strategies which work, and understanding their advantages and limitations is still useful.
(As a general rule, novelty is never the only relevant criteria, real progress is often slow and painstaking, and we can learn a lot from history.)
Anyways… one of the harder parts here is linking in different fields in ways which can be adopted in a broadly useful fashion.
Computing is “old news” in some senses, but it’s relatively new in linguistic and historical senses. And, figuring out how to apply it usefully in our bigger problem areas runs into the limitations of specialists and the incomprehension of non-specialists.
Block programming (or, really, any innovation) seems like it could be promising but runs into problems in the context of widespread adoption. (People who understand things deeply tend to appreciate those things far more than people with flawed understandings. It’s very difficult — and perhaps wrong — to care about something when our ideas of it are distorted and misleading.)
So… “baby steps”…
10.
David Sarma (@davidsarma) | June 21, 2022 at 1:39 pm
One of the problems with a lot of programming instruction is the distance between what someone is programming, and what they already know about, or in better cases, what they want to apply programming to. To the vast majority of people, printing text in a console window just doesn’t seem that compelling (other than maybe to people who want to feel like a “hacker”). In environments with a scripting API and readily available script console (ex. Maya, Blender) you find a lot more everyday users picking up bits of programming as they go, to help with their day-to-day work.
This is where Scratch provides something similar, which often gets left out of a lot of discussions of it: the graphics editor, audio editor, drag-and-drop scene layout environment. These are critical components to providing entities that kids can do “something” with, that they might actually want to manipulate, and then have the programming part be a natural means of manipulating those things. When the quoted text talks about using commands, but not programming constructs, the answer should be, Yes, it’s great that there are useful commands to use that would then motivate learning programming constructs.
In other environments where people get bored, consider, what exactly are you leveraging the computer to do? This kind of “learn programming in the abstract” is what you’re referring to as the sort of “sink or swim” mentality of weeding out the weaklings and only teaching the survivors, rather than doing the hard part of teaching the basics of what programming is about to everyone. It seems like this attitude comes from existing software developers who have no real experience with trying to teach regular people, but rather are engaged in some sort of strategy of flaunting the complexity of software development, and reveling in the undying beauty of intricate abstractions which only the select few can appreciate. Needless to say, that’s not a particularly helpful attitude to have when interacting with people who are trying to learn how to program, and just want to move their cat character across the screen.
11. Links 23/06/2022: digiKam 7.7 and Tails 5.1.1 | Techrights | June 23, 2022 at 12:55 pm
[…] CER ☛ Programming in blocks lets far more people code — but not like software engineers: Response to the… […]
12.
bh | July 4, 2022 at 3:48 pm
Thanks for this wonderful essay.
I confess I don’t understand the claim, which you accept but consider irrelevant, that users of block languages don’t use conditionals and loops. They do if you teach them! In particular, the Create Task in the AP CS Principles course requires students to use and comment on both, and so people who take CSP learn these constructs whether their course uses block or text languages.
As for programming like a software engineer, /first courses/ in text languages don’t teach that either. At a minimum, you need CS 2, algorithms and data structures, but typically there’s a more advanced Software Engineering course that (college) students take senior year. I think it’s problematic that almost all the curriculum using block languages is for a first course. (Tiffany Barnes’s “CS Frontiers” course is an exception.) If I ever get around to rewriting SICP in Snap!, maybe that’ll get people to stop talking about how trivial block languages are.
13.
Alex | January 23, 2023 at 7:16 am
Overall, you definitely call out some fallacies such reports and studies make (generalization of block-based programming, assuming causation when none has been proven, conflating points) but I think you did somewhat of the same on your 3rd key point. This is just a critique on that point since I basically agree with everything else.
Of course software engineering shouldn’t be the goal of introductory computing courses. The main point of these courses is to get students exposed to computing ideas and be able to explore them with the appropriate tools. Teaching them about dependency injection, composition, or code smells is beyond the scope of such classes. If they want to make a animated butterfly or recreate an arcade game on Scratch, let them. It allows them to apply computing ideas to projects that keep them engaged. The majority of software engineering practices should be left to classes focused specifically on that.
But some basic software engineering practices are crucial for beginners and teachers. Proper naming of variables and comments makes it easier to identify what the code is doing. Reducing the depth of nested loops and if statements tends to make the code more readable (while also reducing the runtimes as a secondary effect). More readable code makes it easier for students to identify their own mistakes and teachers to provide feedback. An important part of writing code is also being able to read it. Just like how improving reading skills tends to improve writing skills and vice versa, the same applies to coding. Usually one can’t write a good story if they don’t know how to make it readable.
Instead of focusing on general software engineering practices, most of which students won’t need, we should focus on those that improve readability. It helps them build good coding habits that will help them in the future if they choose to continue studying computing or at the very least improve their current coding experience.
14.
Mark Guzdial | January 23, 2023 at 12:38 pm
Hi Alex,
Thanks for your comment. It’s a great point that we’re thinking about a lot in PCAS, a new program I’m helping to build at the University of Michigan: https://lsa.umich.edu/computingfor/program-overview.html. Just what software engineering skills do non-CS students need? I’ve now taught two classes in the new program, and very few students EVER created variables. In Snap, variables can be as long as you want, with any characters including spaces. Proper variable naming is now different. When we decide that we want to think beyond mainstream programming tools, the definition of what’s valuable from software engineering seems to change.
15.
Dennis Bouvier | January 23, 2023 at 1:06 pm
I agree with Alex in that there are ‘software engineering practices’ that should be taught in the first programming course. Of course, Mark is right, that the software engineering practices that matter depend on the language of instruction; perhaps also, the level of the student/course.
I have recently convinced myself that ‘good variable naming’ is an important, but often overlooked, software engineering practice that could be incorporated into intro programming when using text-based languages … for all the reasons Alex mentions above: aids the student to read their own code, aids the instructor in reading/commenting on the code, but I think also aids the student in writing their own code. It could be that good variable naming is the most important software engineering practice for text-based intro programming courses. Interesting that it doesn’t apply at all in Mark’s context
16.
Mark Guzdial | January 23, 2023 at 8:24 pm
I completely agree about the importance of good variable naming. It’s just a different process in Snap.
I’m finding it absolutely fascinating to design with Snap. I build a LOT of custom blocks these days. Because they’re context even task dependent, I can make them sentence like. One I just built tonight is:
get special pixel of at x y
When students are dragging variables into these slots, they pause and read the sentence to themselves. Does that make sense with this variable? If not, they try a different open slot. It’s so interesting that they can use the keyword parameters to use their English-language skills as a check on their program composition. This would be a very different process if it was getSpecialPixel(costume,xcoord,ycoord).
17.
Alex | January 24, 2023 at 8:04 am
Like Dennis said, which software engineering skills are crucial depend on the language being used. The skills I mentioned (good variable naming, appropriate comments, managing level of nesting, consistent writing styles & indentations) are important for a text-based language. Basically anything that makes the code easier to read. If you struggle to read it, you will probably struggle to debug it.
Perhaps most of these skills don’t apply as much to block-based programming but based on what little I know, proper variable naming is still quite useful on such languages. Using the example you provided: get special pixel of at x y. Without any context, I have no idea what it is about. Is this a global x and y or local to a certain thing? Like you said, it is task-dependent. But if, as you said, students used their English-language skills to name the variables in a way that makes sense in a sentence, then it would be much easier for others to understand. So they could name it like this: get special pixel of at x_of_square y_of_square. Then we would know what the x and y stand for.
But this is just my two cents. I teach using text-based languages but allow students to use block-based ones for some projects. And so far all of the students who have used block-based ones have said they appreciated using good variable names since it helped them better read their code and keep track of what they were doing.
18.
Mark Guzdial | January 24, 2023 at 1:16 pm
Hi Alex,
I didn’t describe that well — I’m sorry. It’s hard to communicate about blocks in a text-only discussion thread.
“get special pixel of at x y ” means that the block is “get special pixel of [. ] at x [. ] y [. ].” X and Y are keywords. They’re not variables. No variables are needed here at all.
My students are using their English-language skills to read their code and decide where their variables fit — which slots they go into. It’s the keywords that make the sentence, not the variables.
Mark
19.
gasstationwithoutpumps | January 27, 2023 at 11:43 am
I’ve not programmed in block-based languages for a while (I was a beta tester of Scratch with my son and some 5th graders about 15 years ago). Variable naming is important and certainly teachable with blocks. Commenting was not available in Scratch at the time—has that been fixed in more modern versions or more modern block languages?
Naming functions to make them look like English sentences probably helps with getting the slots filled right, for functions with few slots (which is all beginners should probably be faced with).
20.
ATLIS 2023 Resources - Gary Stager | May 1, 2023 at 9:06 am
[…] Programming in blocks lets far more people code — but not like software engineers: Response to the…by Mark Guzdial […]