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 12 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: , , .

Getting feedback on Teaspoon Languages from CS educators and researchers at the Raspberry Pi Foundation seminar series New ICER paper award for Lasting Impact: Guest blog post from Quintin Cutts

12 Comments Add your own

  • 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.

    Reply
  • 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?

    Reply
  • 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.

    Reply
  • 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).

    Reply
    • 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.

      Reply
  • 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.

    Reply
  • 7. garystager  |  June 20, 2022 at 7:24 pm

    Mark,

    I would also like to learn more about what you’re doing in Snap!

    Reply
  • 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.

    Reply
    • 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”…

      Reply
  • 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.

    Reply
  • […] CER ☛ Programming in blocks lets far more people code — but not like software engineers: Response to the… […]

    Reply
  • 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.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 10,185 other subscribers

Feeds

Recent Posts

Blog Stats

  • 2,039,880 hits
June 2022
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
27282930  

CS Teaching Tips


%d bloggers like this: