Coding is the process of taking the ideas of an algorithm and translating these into a precise, formal language that’s understood by both the computer and the programmer. In traditional, text-based languages such as Python and C, the programmer does this by typing the code on screen. In visual languages such as Scratch or Blockly, the programmer uses a mouse or their finger to drags building blocks into position on screen, snapping these onto or inside other building blocks. In text-based programming, the programmer writes a program, in visual programming, the programmer builds the program. It’s no exaggeration to say that the work of Mitch Resnick’s Scratch team at MIT Media Lab has played a pivotal role in the global movement to get children coding and thus engaged in computer science. For those teaching, or learning, programming, this visual approach offers many advantages. Let’s think about some of these now.

Firstly, programming is hard, but text-based programming is particularly difficult. One of the reasons is that the programmer has to think about two things at the same time, the semantics of the program, that is what it means, the algorithms and data structures that the programmer is trying to code, and the syntax of the program, that is the particular vocabulary, grammar and punctuation that’s needed to express it in the particular programming language being used. In visual programming, most of the syntax is taken care of by the blocks provided in the language, and thus the programmer gets to focus much more of their thinking on the semantics. If what we as teachers are interested in is developing pupils’ ‘computational thinking’, then visual programming languages make it much easier to emphasise this, rather than having to master the particular syntax of particular text-based languages.

One consequence of the syntax being built-in to the blocks is that it’s all but impossible to make syntax errors when using a visual language. It’s impossible for the programmer to mistype commands, or to use the wrong sort of punctuation or, in most cases, to use the key words of the language in a way that doesn’t make sense - typically the blocks can only fit together in a grammatically correct way. Many of the frustrations felt by those learning to program in text-based languages are due to frequency with which they’ll make syntax errors in their code, which often take quite some time for the novice programmer to track down and fix. Thus visual language programs are far less likely to have errors than their text-based equivalents, and the errors that programmers do sometimes make are likely to be much more interesting, providing much more opportunity for learning from mistakes than simple typos.

In developing Scratch, Resnick and his team were deeply inspired by construction toys, from Froebel’s gifts through to modern LEGO. Whilst LEGO sets typically come with step-by-step instructions, and sometimes we’ll use a step-by-step approach to teaching pupils how to code, younger children will just play with LEGO, making whatever they have in mind through clicking blocks together and seeing what works, and more experienced LEGO builders will range far beyond any step-by-step guides, again letting their imagination take the lead in creating novel, original artefacts. The same is true of visual languages: they have low floors and high ceilings - it’s easy for a young child to start playing with Scratch, ScratchJr or other visual languages, and there’s (almost) no limit to what a more experienced coder can create - check out some of the featured projects on the Scratch community website. Because it’s so easy to playfully experiment in Scratch, pupils can quickly try ideas out to see what difference they make, and to figure out for themselves what works, or what improves their program, and what doesn’t.

Because of the additional cognitive load imposed by syntax, in text-based languages teachers have long though it helpful for pupils to plan their programs first, before they start coding: perhaps requiring them to draw flowcharts or write their programs in some more or less formal pseudocode, even if there’s little evidence that this formal, written planning actually helps. In visual languages, because of the reduced cognitive load, there’s no obvious need to draw flowcharts or write pseudocode, which makes coding in visual languages a far more interactive, engaging process for the young programmer. Whilst teachers do sometimes still expect pupils to write out plans or to draw designs for their visual programs, children working in Scratch outside of school rarely seem to see the necessity for this, typically preferring to think at the screen, trying ideas out as they occur to them. This seems a lot closer to what ‘real’ programmers do in agile software development.

Because the blocks are already visible in the visual language’s editor, programmers using a visual language don’t need to remember that keywords of the language - there’s an immediate visual prompt for all of these. Furthermore, being able to see all the blocks available encourages a playful, experimental approach to mastering the language: learners can figure out what a block does for themselves by just using it in their code.

Visual languages in general, and the ScratchJr / Scratch / Snap! family in particular, have taken accessibility and inclusion seriously. ScratchJr is an (almost) entirely visual language, using icons rather than text to indicate the function of a block, thus making it accessible to pupils who’ve not yet learnt to read. Scratch and Snap! have extensive support for international languages, with both interface and language keywords translated into many languages and the ability to swap between these at the click of a mouse - the keywords of the language can be shown in English, Arabic or many other languages. Scratch and Snap! also make it possible for pupils to take inclusion into account in their own programming: both now offer text-to-speech tools, Snap! has support for speech to text and this is under development for Scratch. Scratch has an extension which provides access to Google translate in pupils own programs, and works well with physical computing devices such as the Makey Makey and micro:bit. As well as low floors and high ceilings, these languages have wide walls.

By making it as easy as possible to learn the programming language, visual programming languages make it possible for young programmers to acquire a sense of mastery of the tool, of fluency in the language. After an introduction to the language, and plenty of opportunity for play and experiment, many children pass beyond learning to code to being able to express their creative ideas fluently through the medium of code: instead of spending time learning the language, they can spend their time building, making, experimenting and sharing. They can also use visual languages to take their knowledge of computer science to new levels, such as using higher-order functions in Snap!, learning about object orientation in GP, developing mobile phone apps in App Inventor and developing machine learning applications using the machinelearningforkids extensions to Scratch.

One final point, about Scratch in particular rather than visual languages in general, is that there is a vibrant, global community of users, providing support and encouragement to one another. The Scratch editor has a ‘share’ button built in, allowing registered users to publish their code for the world to see, receiving feedback, likes and love from their peers. Scratch has a culture of remixing code too, with young programmers taking others’ code as a starting point for their own projects, or just as a way to figure out how something can be done.

So, visual languages have much going for them, both within and beyond the classroom. Is there a downside? Do these languages have disadvantages?

Well, one is that they feel quite toy-like. Flexible as LEGO is, it’s still a toy: whilst professional architects might still use LEGO as a thinking or design tool, no one would build houses or office blocks out of it! Visual languages are, at present, much the same: they’re great for learning to code, and as a playground or testing ground for ideas, but production applications are developed still in text based languages, and so, sooner or later, anyone aspiring to a career in software engineering is going to need to learn a ‘proper’ text based language. Some languages make this transition easier than others - the paths from Scratch to Python or Javascript are well-worn ones, and there are projects which take the syntax of Python or Javascript and make this available as blocks, as well as tools, such as Microsoft’s makecode editor for the micro:bit, which allow the programmer to swap between text and blocks.

Because of the click and drag, palette based interface there’s also a limit to how quickly code can get written in visual languages - once a programmer has mastered the syntax of a text-based language, they can write programs as quickly as they can type text, and make use of code completion and copy and paste to speed this up further still. Snap! can be used from the keyboard, with blocks appearing in the editor as the language keywords are typed in, but the interface is still a visual one, and typing in Snap!, whilst quicker than hunting for blocks in the various palettes, still seems to lag behind the speed that an expert coder can achieve in a good text editor.

Disadvantages such as these apart, visual languages are, with rare exceptions, Turing complete: any computational problem that can be solved in a text-based language can be solved in a visual language. They’re also a far, far easier and more engaging way to learn to program than text-based languages can offer.