Wednesday, 13 July 2016

Graphical vs Text-Based Coding for Kids


It's often assumed that children need to progress from graphical programming languages such as Scratch to text-based programming languages such as Python or JavaScript. I find this ironic as I spent much of my career working on developing graphical languages to make software development more accessible to adults with subject knowledge rather than coding expertise. I also spent a lot of time developing software using graphical languages (often with some text mixed in.)

This article is going to get into some detail. For parents wondering whether their child needs to move on to a text-based language, the summary is:
  • Graphical vs textual isn't really that important an issue. 
  • It's whether a particular language allows your child to do what they want to do in a way that's efficient and enjoyable for them. 
  • Start with what they want to make and find a good language for that which is suited to their expertise level and the way they think. 
  • It's a myth that adults don't use graphical languages. They do. 


For more information see Pixel Art Advent Calendar - A Chocolate Alternative

Why are we Teaching Kids to Code?

First let's take a look at why we are teaching kids to code. Some kids are the programmers of the future. Other kids will have jobs that require some element of coding to support other skills. Others will just need to have been exposed to coding to have a better understanding of the world they live in and to be able to take control of it.


    What are we Trying to Teach Kids?

    When teaching young children, my goal is not to teach them vocational skills. I'm trying to teach two major things:


    1. the ability to make projects that are useful / interesting / entertaining to them now and,
    2. transferable knowledge about computational thinking that will enable them to make things that are useful / interesting / entertaining / profitable in the future.


    When you're teaching teenagers who are interested in programming, robotics, etc then learning relevant industry skills becomes a factor. You can also make this case for highly able younger children, especially when they have parents who are willing to help them use programming languages they are familiar with but are less motivated to help with children's programming languages.


    What is a Graphical Language / Text-based Language?

    It's easier to define text-based programming languages. These are languages that are typed using a keyboard and stored as text files. 

    A graphical or visual language typically uses drag and drop rather than typing. It may use icons or textual labels on blocks or elements. GUI elements such as dialogues and drop down selection menus are often used.

    Block languages such as Scratch and Blockly-based languages are very popular for children. 

    Typically when people talk about text-based languages they are referring to programming languages such as Python, Lua and JavaScript which are 'real' programming languages that are used by professional software developers. 

    Interestingly there are text-based programming languages for children such as Logo and Sniff (based on Scratch, but textual) which can be seen as a stepping stone between graphical languages and textual ones. 

    Ease of Learning / Remembering

    One of the important features of graphical languages is that children don't have to remember a list of commands or a complex syntax, it's just there in the environment. This is such a huge thing when kids are learning a programming language. 

    A lot of professional software developers spend tens of hours each week programming in the same language. This means they can remember lots of knowledge about syntax and APIs so it's instantly available when they need it.

    Kids tend to have other commitments. Many children will only write code once a week in a 45 minute lesson for a few weeks each year so they never reach mastery and are constantly needing to look things up.

    My younger son loves to use SAM Labs electronics components to make crazy contraptions. He can easily go a few weeks between using them and still be able to instantly remember how to connect them up in the graphical editor. If he was using a text-based language to achieve the same thing then I'm sure he would find it harder to pick up where he left off. In fact, SAM Labs does use text-based coding to go beyond the basics, and I forget how to use it in between sessions when I help my son (the sooner they can move more of that capability up into the graphical layer the better.)

    Of course, it's possible for a programming environment to help with the ease of learning and remembering for text-based languages. A good IDE (integrated development environment) helps with this a lot. But the breadth of a typical programming language makes it harder to present the whole language in such an accessible way as in Scratch or a Blockly-based language.

    Syntax Errors

    Syntax errors are a pain for adults and kids. Who wants to spend ages working out that they've missed out a colon that should obviously be there, counting brackets or spotting a spelling mistake?

    Yes, good editors can help you spot these errors, but even better editors mean that you can't make those mistakes in the first place. In Scratch you work directly with a coding concept rather than having to break it down into something you can type. (This can be frustrating if you want to swap a repeat for a forever loop for example, but that's not a hard thing to do, it's just work - the tricky thing is made easier.)

    Kids often don't have access to the best tools so end up in situations where they do struggle with syntax errors. I've found that Code Combat is a great way to introduce kids to text-based coding and IDEs, but it's not a generic programming environment.

    There are efforts to bring the benefits of graphical editing to text-based environments for children (such as Frame-Based Editing.)

    Icons vs Text

    Some graphical languages rely on pictorial symbols or icons, for example LEGO Mindstorms uses an icon-based notation in its software.

    Pictures are often used to enable children who can't yet read to code. Once children can read, an icon-based system need to be very well designed to compete with textual labels. If a child is having to map from a picture to a word in their mind to understand what they're seeing then you've just added additional complexity.

    Languages such as Scratch and Blockly use textual labels on graphical elements that can be dragged around. In my experience this works really well for children who can read.

    Graphical Doesn't Mean Dumbed Down

    Professional software developers often assume that languages such as Scratch are 'dumbed down' versions of programming.

    That's not the way it works. What Scratch does is remove the extraneous details that aren't actually necessary so that kids can quickly get from an idea to running code.

    Instead of spending ages discovering that they have missed a colon from the end of a line, kids are able to spend more time thinking about the logic of their project. They actually spend more time on computational thinking and less on keeping the computer happy.

    Scratch can be as difficult as you need it to be. You can draw fractal trees and hit complicated synchronisation problems.

    I looked at this topic in more detail in Scratch isn't proper computer programming is it?

    Linear vs Alternatives

    One of the features of text-based languages is that they are inherently linear. Text-based languages aren't good at showing connections between different bits of code (though of course those connections are there and must be worked out by a parser.) 

    Graphical languages typically support non-linear layout. Modern programming, especially games, hardware and internet-of-things based coding is often event-based and concurrent. Code isn't like a book, it doesn't progress sequentially from beginning to end.

    In Scratch I can lay out code to move a sprite like this:



    This maps directly to the actual movement of the sprite (and to the keyboard layout.) In a text-based language it would need to be placed in an arbitrary sequence and you would lose that additional information.

    I took a look at Sonic Pi, a text-based language for coding music and found it very disconcerting to have to place code that runs concurrently in a linear sequence.

    Scratch has the ability to layout code in 2D space so if you're writing music that runs concurrently you can organise it horizontally, or place it in different sprites that automatically run concurrently. Concurrency is a very natural concept in Scratch.

    Scratch is still mostly linear though. It can be difficult to understand behaviours that depend on one sprite broadcasting a message and others receiving it. 

    Wonder Workshop have taken a different approach with their Wonder language for the Dash & Dot robots. This uses a flow-based approach. Flows are often used in describing business processes in a precise (and sometime executable) manner. State machines are often used in control systems and are a useful way of capturing the behaviour of systems that behave differently depending on their current state.

    Coding in Minecraft is very interesting, it mixes textual commands and blocks in 3D space. The code is actually part of the world, and to a lot of kids Minecraft is just as real as the real world. (Think Internet of Things and then some!)


    (I haven't even touched on teaching children about artificial intelligence and machine learning which requires different styles of language, more on that in future.)

    Graphical isn't Necessarily Slower

    Adults who don't spend a lot of time with children who are learning to code often assume that coding in a graphical language is slow. It might feel slow to an adult who is comparing with the time it would take them to write code in a text-based editor.

    Very few children can touch type so actually watching them type textual code is a very painful experience. (Yes they should learn to touch type, but that's another topic!) They also introduce lots of errors like spelling mistakes and extra spaces.

    Also most of coding time is thinking time. It's working out what you want your app to do and which code to use that takes most of the time, not actually entering it into the computer. 

    What about Touch Screens?

    For many kids growing up now their first experience of a computer is a phone or tablet with a touch screen. Graphical languages translate very well to a touch interface. Lots of young kids can work much more quickly with a drag and drop interface on a tablet than they can with a keyboard and mouse/trackpad. And lots of teens have a phone with them at all times.

    There are lots of apps such as Scratch Junior and Pocket Code that use a touch interface effectively to allow the phone/tablet generation to write code.

    Microsoft have created the Touch Develop language with phones and tablets in mind. It's textual, but reduces the actual typing required by using a tap interface. This is definitely an idea worth exploring.

    Apple are launching the Swift Playground app which will teach children to write the textual Swift language but using the multi-touch capabilities of the iPad.

    Children are often Creating Graphical Apps

    Children are often creating graphical apps and games. Graphical languages often have a closer connection between the end result and the language used to create it.

    For example you can click on a sprite in Scratch to edit its code. This direct connection reduces the cognitive overload in developing a graphical app.

    In Minecraft the code is actually built into the environment. Control flow is achieved with redstone dust which is placed in the game.

    Kids like Graphical Environments

    Most kids prefer a graphical environment, it's more fun and feels less like hard work. A text-based environment can seem quite dry. Companies like Tech Rocket are trying to make text-based coding more fun - see their free Python Tutorial.

    Harder isn't Better

    It can be really frustrating for a child who is good at coding games in Scratch to move to an environment where it's actually harder to create similar games. It's not 'more grown up' to have to do more work than necessary.

    Sometimes it's necessary to make things harder as a trade-off to get more flexibility. But in other cases I think professional software development languages and environments could learn a lot from Scratch and similar languages.

    What about Graphical and Text-Based?

    There's a trend towards offering children tools that allow a block-based and text-based view of the same code with the text-based view being a 'real' programming language.

    For example this is offered in Code.org, Code Kingdoms and the Microsoft micro:bit block editor.

    My 9 year old is currently learning to code Minecraft mods using Java with the Code Kingdoms block-based editor.

    This is quite a good approach although it can drag some of the baggage from text-based languages into a graphical environment.

    What about Kids Versions of Languages?

    The Ready programming language allows children and teens to write games in an environment that runs on top of the Unity games engine.

    This is an interesting approach which addresses one of the main criticisms of languages like Scratch - you don't end up with an app that you can just run outside of Scratch or submit to an app store.

    Adults use Graphical Languages too

    Graphical languages can be more efficient when used only for occasional tasks, or by people who have subject knowledge rather than just being programmers.

    Programming is increasingly entering everyday life. IFTTT (if this then that) is a very popular service that allows people to automate their lives. It uses a visual editor to create rules. You don't have to learn a complicated syntax to use IFTTT you just use a custom editor. Is it really coding? Well it achieves something that you would have to write code to do otherwise, it's what's needed to enable more people to code their lives without needing to learn a complex language.

    Games engines often combine graphical editors with text-based code for lower level details.

    Software companies are always looking for ways to enable less-technically focussed 'business users' to program solutions. These users typically understand (and are defining) the 'business processes' for their organisation which determine things like how a bank account operates or how discounts are applied. They need to be able to accurately specify this behaviour so that a computer can execute it but they don't want to be worrying about things like syntax errors, importing libraries and casting an integer to a string so that you can include it in a message.

    There's also a trend towards enabling adult non-experts to use visual languages to allow them to get up and running quickly. For example, this article gives lots of examples for visual programming for the Internet of Things. For many people coding is a means to an end, not the end itself! If block-based environments make coding accessible to more people that's fantastic.

    Maybe a lot of the children learning to code today will end up using graphical languages in their jobs and hobbies rather than textual ones.

    Some Kids will Love Text-based Coding

    Some kids will absolutely love text-based coding from a young age. There's certainly no need to stop them and every reason to encourage them.

    Plenty of young children are capable of writing HTML & CSS and learning Python, JavaScript or Lua. And for some the lure of writing Minecraft mods will get them learning Java. At the moment those languages are the best tools for many tasks. And some kids will just love learning to program for its intrinsic academic value.

    This is all great stuff. I would have been one of those kids! (It was Spectrum Basic and C on the Amiga in my day though.)

    But it doesn't mean that all young kids need to learn a text-based language or that text-based languages are 'better'.

    Summary

    Text-based coding isn't the goal for young children. Coding in Scratch and other graphical languages isn't just a stepping stone for getting to Python and Java. It's useful in its own right and some children will go on to use graphical environments as adults.

    The goal is to give kids the skills to make digital projects and to give them transferable skills that apply whatever programming language they are using.

    Of course some children will go on to be software developers and they will need to learn the languages that are in use in industry. But they should learn a text-based language because it's the right tool for the projects they're trying to build, they are interested and/or it's a useful vocational skill and it should be when their typing is good enough to avoid frustration. Until then, there's plenty to learn from graphical programming languages.

    I'd rather teach a child to be able to use Scratch to create fantastic projects enthusiastically than have the same child struggling with syntax in a text-based editor. They will have learnt far more about computational thinking and have a better understanding of the world of technology around them.


    Next: Why Should Kids Learn About Robotics?




    More from Tech Age Kids:

    Comments:

    Howard said...

    Great post with many excellent points. I love how Scratch quickly and easily allows kids to make things which are enjoyable and rewarding to them. This has been achieved by removing unnecessary complexity in both the Development Environment and the language as you have described. With languages there is often a trade of between complexity and how application specific they are. With Scratch they have traded this complexity for making certain types of graphical games quick to do. I think the amount of creativity the kids are able to employ in their programs is a good measure of the success in Scratch.

    That said, the principle challenge of writing software is often expressed as managing complexity. And to do this there are numerous software practices and principles which can be employed to help achieve this. Things such as Encapsulation, Abstraction, Design Patterns, Functional Decomposition etc etc. General purpose languages such as C/C++, Java, Python, C#, etc are excellent at supporting the use of these techniques to allow complex programs to be created. The simplifications made to Scratch, while allowing it to do what it does well, make it more difficult to demonstrate some of these programming principles.

    Is this important? Well that depends. This does not take anything away from Graphical languages, they allow kids to create things which is great and adults to configure the heating to come on at the right time etc etc. But if you are interested in progressing to what I might loosely describe as general programming, either for fun or work, then learning the broader practices and principles of good software development become more important. And I question whether Graphical languages are best for doing this.

    Tracy said...

    In my experience graphical languages are actually much better at expressing the complexity of large systems. Good IDEs that draw on techniques from graphical editors can help a lot by surfacing the semantics that is lost in a textual format.

    For adults who are experienced with a language and type quickly text is better for the lower-level details (the kind of thing that Scratch does let you express), though that might just be because we haven't developed better alternatives yet.

    Scratch is actually pretty good for developing the early skills you need to build complex systems later, you have multi-threading and broadcasting messages, you organise code into sprites and create clones, you can create custom blocks and even cloud variables. Clearly there's a limit and kids will graduate from Scratch at some point, but they can certainly learn transferable software engineering skills rather than just coding skills.


    Howard said...

    I would agree that a problem domain specific graphical language can lower the 'representation gap' for that problem domain. I would be interested in knowing if you have seen this work well for a more general purpose graphical language.

    I agree that Scratch is an excellent starting point which teaches much. It's just that at present, and I admit I haven't the same experience with it as you, I also see much value in learning from more general (text) languages.

    Tracy said...

    UML is pretty general purpose and can be executable. But there's an interesting aspect to more people being able to write code - it may make sense to develop more domain-specific languages. Having the right set of concepts for what you're trying to do makes coding much simpler whether it's graphical or textual.

    I'm definitely not arguing against text-based languages being useful, just that graphical languages are more than just a stepping stone to be jumped over as soon as possible.

    Derek Breen said...

    This is the best/most thoughtful article I have seen about teaching blocks-based (à la @Scratch) vs. text-based (à la Java) programming. Just shared it with everybody I know in the ed-tech world! I found this ESPECIALLY well put: "Professional software developers often assume that languages such as Scratch are 'dumbed down' versions of programming. That's not the way it works. What Scratch does is remove the extraneous details that aren't actually necessary so that kids can quickly get from an idea to running code. Instead of spending ages discovering that they have missed a colon from the end of a line, kids are able to spend more time thinking about the logic of their project. They actually spend more time on computational thinking and less on keeping the computer happy."

    Tracy Gardner said...

    Thanks Derek, glad you liked it. The more I watch kids use Scratch (and the Blockly-based languages it has influenced) the more I appreciate it. I wrote this after yet another discussion about 'when kids should move to a proper programming language' with someone who had clearly not understood the real value of Scratch.

    Derek Breen said...

    Yeah, I can't tell you how many times I've had that argument since entering the blocks-based-teaching-sphere five years ago. I'll never forget the moment last fall when a high-level SAP programmer came over to me after a workshop. We were both in Cape Town, South Africa as volunteers for Africa Code Week. He had never seen Scratch before, while I had just gotten my first Scratch book published. He said he had no interest in Scratch until he watched a student create a pretty complex game; this is when he suddenly realized the structure of the child's code was much closer to how he uses modern programming languages, only he uses "libraries" instead of blocks. He was particularly blown away by knowledge students demonstrated of object-oriented programming. This is often lost on traditionally-trained computer science teachers who literally can only think of code in a linear fashion, in the nature of the languages they were trained on in the 80s/90s and even (sadly) in more recent years (something I've now observed in many countries).

    I can't wait for you to see the forthcoming blocks-based programming language, GP, which former developers of Scratch and Snap are now working on (you can read a bit about it in their first official blog post from a few months ago: https://goo.gl/dU3L3V).

    Post a Comment