Introducing GP: A General Purpose Block Language

June 13, 2016 at 7:28 am 26 comments

GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).

GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.

What makes GP remarkable is that it aims to be a general purpose language. John’s vision for GP is to be the language that students might move to after Scratch, with the highest possible ceilings. Think about GP as Python or Smalltalk in blocks — and even more the latter than the former. From the virtual machine (VM) on which it runs to the class browser, GP feels like a blocks-based form of Smalltalk. Because GP is VM-based, it’s portable — there are versions for Mac, Windows, iOS, and even a JavaScript implementation of the VM so that GP runs in the browser.

GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”

GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.

A brief tour of Smalltalk-like features of GP

When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.


There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.

I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)

Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.


The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.


Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!

One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.

The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)


I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.

My thanks to the GP team for review and comments on drafts of this post.

Entry filed under: Uncategorized. Tags: , , , , .

Final Review Period for the K-12 CS Framework for K-12 Computer Science Education June 8-29 An Ebook Integrating Minimal Manuals with Constructionism, Worked Examples, and Inquiry: MOHQ

26 Comments Add your own

  • 1. Bijan Parsia  |  June 13, 2016 at 7:57 am

    I have to say that I’m pretty skeptical. Or rather, I’m curious as to what the expected benefits are (for general purpose programming). It is intended primarily for casual users?

    One of the big claims for visual programming languages in, say, the 80s and 90s was “no syntax errors”. But I don’t know what research showed that syntax errors were a significant problem? And what’s the big advantages of blocks over Prograph like structures?

    It can be fun, of course. Scratch is fun. But I wonder if it’s focused at the wrong level. I’m not sure that *statement* level issues are all that significant as opposed to managing larger units of code and the code visual behaviour mappings.

    • 2. Andromeda  |  June 13, 2016 at 8:53 am

      My understanding is that GP is at least in part an answer to the question “after Scratch, what next?” Therefore it’s pitched at a slightly older audience; has the capacity to slide between visual mode and text mode; and has much more capacity to interact with object in the physical world. It starts from a Scratch-like paradigm and can thus be instantly familiar to Scratchers, but gives them much more real-world programming power, and provides a stronger bridge to other, non-visual languages. So when you’re thinking about what level it’s focused on, don’t think statements vs larger units of code; think 16-year-olds vs 10-year-olds.

      Mind you I haven’t played around with GP myself. But my daughter (an avid Scratcher) *has*, so I’ve poked around the documentation.

    • 3. Mark Guzdial  |  June 13, 2016 at 12:59 pm

      We have evidence that syntax errors are a significant source of drop-out in our studies of adults learning CS on-line. Matt Jadud’s studies of undergraduates learning Java show that minor errors (e.g., wrong semi-colons) can lead to half-hour long delays in completion. Neil Brown’s studies of the Blackbox in Java point out the compilation errors that students don’t recover from. So yes, syntax is an issue.

      The studies by Marian Petre and T.R.G. Green ended up saying that text programming beat visual in all their studies, but that’s because people know text better than pictures. They suggest that things might be different if people spent the time learning visual programming and got better at it. Today, most kids start programming with Scratch or Blockly. Does that change the story? Maybe — worth exploring.

      • 4. TN Free Blocks  |  June 14, 2016 at 5:54 am

        “Matt Jadud’s studies of undergraduates learning Java show that minor errors (e.g., wrong semi-colons) can lead to half-hour long delays in completion.” That’s my experience, too.

      • 5. Bijan Parsia  |  June 14, 2016 at 7:59 am

        Ok, so it’s for getting people past that drop out stage? That seems reasonable, but then I wonder whether structured editors, DWIM, etc. wouldn’t work as well.

        Anyway, interesting.

        • 6. Mark Guzdial  |  June 14, 2016 at 8:30 am

          Completely agreed! That’s why the BlueJ team is now exploring frame-based editing. We need more experiments.

          • 7. Bijan Parsia  |  June 14, 2016 at 3:01 pm

            Oh, one other bit. It seems quite possible to have syntax errors in Scratch. I vaguely recall getting frustrated by some of the drag fails I was experiencing, so I fired up some Scratch to try and sure enough, there’s definitely something hinky about e.g., play sound and repeats. It’s very wacky!

            I wonder if it’s the executability (even if with unintended effects) that makes it approachable. Consider, HTML, where it’s pretty simple to get *something* on the screen, though getting *exactly what you want* is very challenging (or even getting predictable behaviour can be hard).

            • 8. Bijan Parsia  |  June 14, 2016 at 3:03 pm

              From the Scratch paper :

              “Similarly, Scratch has no error messages. Syntax errors are eliminated because, like LEGO⃝R bricks, blocks fit together only in ways that make sense. But Scratch also strives to eliminate run time errors by making all blocks be failsoft. Rather than failing with an error message, every block attempts to do something sensible even when presented with out-of-range inputs. For example, the “set size” block bounds the range of its parameter so that it cannot make the sprite excessively large (possibly exceeding system limits) or invisibly small.”

              So, Javascript, HTML, CSS, Interlisp, really anything with DWIMishness sort of gets this. It would be interesting to tease out the failsoft issues from syntax error issues.

              • 9. Mark Guzdial  |  June 14, 2016 at 3:05 pm

                JavaScript is definitely *not* like this. Look at the Weintrop and Wilensky paper which directly compares a blocks-based language (Blockly) to JavaScript. JavaScript syntax makes it much harder to read and debug code.

              • 10. Bijan Parsia  |  June 14, 2016 at 3:34 pm

                I thought Javascript has permissive parsing? I.e., you can have some errors and still run the program? I.e., “failsoft”? Perhaps I misrecall or maybe there’s not enough failsoft, or that DWIM failsoft doesn’t lead to sensible enough programs?

                I think you need to sort of different classes of syntax errors, even besides “compilable” vs. “logic” error.

                Looking at that paper…hmm, I’m not so convinced yet (on first glance). There’s lots of possible syntax confounders (e.g., using different constructs, i.e., repeat 2 vs. for (var i = 0; i <2 ; i++) (as in Figure 5).

                Performance: "On these two questions, students performed significantly better in the graphical condition (83% correct) versus the text-based for loop version of the question (16.1% correct). "

                I mean, that seems to be more a difference in control structure than syntax (i.e., block vs. text). In the generalised for loop you have auxiliary variables (that aren't used), assignment to those variables, comparison, 0 based counting (and a strictly less than), plus an incremental operator. None of these are necessary!

                Figure 6 gets closer to parity (though you still have an increment operator) and performance becomes similar: "On this question, students performed comparably, answering the question correctly 19.6% percent of the time in the graphical condition and 18.0% of the time in the text-based condition."

                (They of course give this very analysis. But…then I think in order for any comparison to work you need to match constructs closely between a blocks and text representation.)

                And, of course, this is all reading, rather than writing.

    • 11. alfredtwo  |  June 13, 2016 at 3:32 pm

      My students run into lots of problems with syntax. That is one reason why I like the idea of a general purpose block language. I get frustrated by the limits of existing languages which seem locked into small domain specific environments.

  • 12. Mark  |  June 14, 2016 at 4:00 am

    Agree that syntax errors are a major stumbling block and reason for adults dropping CS. My experience however is that once a syntax based language is learned to a level of proficiency, block languages are frustrating because it is easier and quicker to write one or two lines of code than it is to search for and implement the blocks needed to do the same thing. I wouldn’t write a letter using block sentences

  • 13. Mike  |  June 14, 2016 at 1:12 pm

    The ‘blocks-text’ slider is fascinating (especially the idea that it might show an in-between state with some blocks and some text). I’d be interested to know if this helps people make that jump from drag-and-drop programming to textual programming.

    As someone who’s programmed professionally via a textual language I wonder what could be done to ease the pain of using a graphical language. Specifically, could things like keyboard shortcuts and/or a ‘most recently used’ panel and/or a ‘favorites’ panel make it easier to grab the piece you want without having to scroll through panels and panels of pieces?

    • 14. Mark Guzdial  |  June 14, 2016 at 1:32 pm

      The GP team is explicitly exploring those issues. Check out their VL/HCC paper here:

      • 15. Mike  |  June 14, 2016 at 4:48 pm

        Thanks for the link! It was a great read (and concise, too).
        The Google-style completion list is a really good idea and would be interesting to see in action.
        I wonder if one could start with blocks, move to the ‘compact, undecorated blocks’ (experiment #2), move to typing-with-completion in GP (experiment #3), and then move to textual language + IntelliSense/autocompletion.

  • 16. Garth  |  June 14, 2016 at 1:32 pm

    Scratch to Small Basic to Python to God knows what always seems like an optimal progression at the high school level. Is something else really needed in there? Sooner or later line code with syntax is going to rear its ugly head. I agree with Mark’s point, once something like Python, VB or Java is learned going to a DnD language is just a pain.

  • 17. David Young  |  June 14, 2016 at 4:01 pm

    Where a blocks-based general-purpose language prevents the casual/beginning programmer from being derailed by syntax errors, it seems to leave alone the greater part of the programmer’s problems, including specifying their solution in many detailed, abstract-symbolic steps, and then diagnosing and fixing the inevitable oversights and errors.

    I am inclined to doubt that general-purpose languages are ordinarily appropriate for “casual programmers” to use to make “spontaneous” software, when they do not seem to be especially suitable for pros to use that way. Before plunging into a general-purpose language, many experienced programmers will try to tackle a problem at a higher level of abstraction by recording a macro, writing a command-line pipeline or a script. Frequently that tips the effort-to-results ratio to results and in that way saves a lot of time and/or frustration.

    There are too few layers of abstraction between computers’ “user surfaces” and the silicon. Students and professionals both would benefit if there was more deliberate attention to creating new layers. Or so it seems to me.

    I’m really enjoying reading the perspectives on block-based programming here.

    • 18. Andromeda  |  June 14, 2016 at 5:18 pm

      I think this is taking an expert’s view of beginners’ problems, and beginners’ views might be quite different.

      Using a macro or a command line tool instead of a general purpose programming language is great if you have all those tools in your belt – but casual programmers may only have *one* tool, and therefore it is the one they will reach for.

      Syntax errors are hugely derailing, and getting anything to work at all takes up a lot of a novice’s time; the problems of software *architecture*, where advanced programmers spend so much of their time, may be entirely off a novice’s radar. Indeed, casual programmers might well google for something related and modify it to suit their purposes, in which case specifying the solution does not even come up, and avoidance of syntax errors is a large part of the task at hand!

      (As a software developer I spend a lot of my time at the higher levels you talk about. But as someone who teaches programming to novices – novices who moreover don’t want to become software developers, just to have a useful tool for problems that arise in the context of their work – and as the mom of an avid Scratcher, I see people spend a LOT of time on those other levels. And my kid *does* in fact use Scratch to make spontaneous software all the time; it’s become a genuinely expressive, creative tool that she frequently reaches for when she has ideas she wants to play around with.)

      • 19. David Young  |  June 14, 2016 at 8:38 pm

        I did not mean to suggest that anybody should use command lines or macro recorders instead of GP, especially not such CLIs/recorders as exist, today. Rather, it seems to me that there are too few tools addressed to problem solving at too few levels of abstraction. Macro recorders are few and far between, and the CLI has many problems, not least of which are the arcane syntaxes, poor discoverability, and the ossification of the category.

  • […] alternative models of ebooks — maybe closer to e-pamphlets. Since I was working with GP (see previous post) and undergraduate David Tran was interested in working with me on a GP project, we built a […]

  • 21. Visto nel Web – 240 | Ok, panico  |  June 19, 2016 at 1:35 am

    […] GP: A General Purpose Block Language #:linguaggi di programmazione ::: Computing Education ::: Scratch […]

  • […] I’ve been using blocks-based languages lately (see my posts on GP and MOHQ), I’ve been thinking more about the challenges of using blocks-based languages, and […]

  • […] També podeu veure el llenguatge visual per blocs de propòsit general: GP. […]

  • […] organize a workshop with John Maloney, Yoshiki Ohshima, and Jens Mönig on GP. I blogged about GP here, and about the use of GP for Media Computation in a minimal manuals structure here. The workshop […]

  • […] understandable if you knew any programming languages. I used a blocks-based language.  I did my livecoding demonstration entirely in GP. I tested their knowledge, too, asking for predictions (as I do regularly, having read Eric […]

  • […] the powerful new blocks-based programming language (that I wrote about here, helped show at SIGCSE 2017, and used for MediaComp in a new kind of ebook here), is available for […]


Leave a Reply

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

You are commenting using your 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


Recent Posts

Blog Stats

  • 2,039,875 hits
June 2016

CS Teaching Tips

%d bloggers like this: