Identifying Characteristics of Block-Based Programming Languages Supporting Children in Learning Robotics Programming

Jan Willem David Alderliesten [email protected] Cas Buijs Floris Doolaard [email protected] [email protected] Arthur Guijt Lars Stegman [email protected] [email protected] Jesse Tilro [email protected]

Abstract Block-Based Programming Languages are a different approach to teaching children robotics programming. Studies analyzing these languages have shown them to be an effective means to this end. Nevertheless, few studies have been able to address concrete characteristics that are defining the effectiveness of these block-based programming languages. In this literature review we analyze other studies revolving around block-based programming languages and their applications for teaching robotics programming to children. This paper identifies five different characteristics of block-based programming languages that support children when learning robotics programming: providing a tangible user interface, enforcing constraints on block shapes to prevent syntactic errors, age selectivity for either a drag-and-drop or point-and-click interaction style, viewing multiple visual representations of a program, and guaranteeing age appropriate content. It is concluded that there are problems in teaching robotics programming to children that are currently not solved by block-based programming languages, suggesting a direction for future research on this topic.

Keywords. - Block-based programming language, programming, educational, robots, programming language characteristics, children, literature study.

1 Introduction

Block-based programming languages (BBPLs) have been utilized for robotics programming since their inception, and multiple BBPLs have been focused on finding an accessible manner of teaching children robotics programming. This paper aims to identify aspects of both the block-based programming field and robotics-based block-based programming which assist in the educational development of children.

1 1.1 Importance of Teaching Children Programming

In a description regarding the relevance of BBPLs, Bers et al. make the claim that coding (programming) is akin to a new literacy [50]. With the increasing impact technology has upon the lives of children and the occupations they will fill, the ability to navigate, understand, and knowing how to program computational systems will be an expected core qualification. By introducing the skill of programming to a child at a young age, the interest in the field can be started and the probability of a child entering the field of programming can be increased. This trend was found by the Information Technology and Information Foundation when comparing the Advanced Placement test scores of children who were exposed to computer science concepts at an early age versus those who were not exposed at an early age [40]. This provides them with new career opportunities and a skill set that makes a child more useful within the future occupational field. Apart from generating an interest in the field of engineering, learning computer programming at an early age seems have other, more generally applicable, significant benefits. For example, professor Marina Bers from Tufts University has done a number of studies establishing the fact that learning to program assists children in developing sequential thinking: a component of planning involving putting objects or actions in the correct order [32, 33, 51]. Furthermore, studies have shown that computer programming for children positively affects the development of a range of various cognitive skills, like reflectivity and divergent thinking [10]. In general, learning computer programming, especially for applications like robotics and BBPLs, is shown to contribute to developing a specific form of thinking often called ”computational thinking” [2, 5, 7, 37, 42, 54].

1.2 Block-Based Programming Languages

Block-based programming languages present a specific subset paradigm within the programming community, due to their focus on visual display of computer logic to create a computer program. Traditional programming languages focus on efficient and optimized means of developing a program, including through the means of programming paradigms involving practices such as singletons, extensions, and a hierarchy-based architecture. Alternative functional programming languages focus on recursive methods to efficiently calculate and solve problems. BBPLs place a significantly major focus on providing an ordered and visual flow to solve a problem. This allows greater accessibility to those not familiar with programming concepts or language behavior, and opens up the development field to a greater audience. BBPLs also provide an effective way for children to discover programming, as sequential consequences and ordering presented within BBPLs are graspable concepts for young children, and it matches the line of reasoning they are taught within basic arithmetic [23]. This makes BBPLs ’suitable for early programming education’ utilization. This therefore provides a unique aspect to BBPLs which warrants their study.

1.3 Robotics Programming

When teaching children educational concepts, the rate of understanding is increased when a tangible and visible aspect is added to the process [3]. This visible aspect not only relates to the BBPLs themselves, but also to the object upon which they have an effect. A robot provides a tangible and interacting interface which allows a child to view the effects of their work, but to also validate the desired sequential behavior with their program. An analysis revealed that while traditional programming exercises suffer from a level of impersonal interaction, a robot introduces both interaction and a set of problems that are not usually found at a software level [15], such as the inability to terminate during execution.

2 Consider a robot moving across a simple Cartesian plane. The transformations required are among the x- and y-coordinates, meaning the robot can move to the left, the right, up, and down. A child is able to grasp these concepts and see the results of their implementation by verifying that the behavior of the robot matches their intentions. The robot also allows the verification with interactive and physical objects located in the real world, as opposed to verification by a movement of a sprite on a screen. A final contributing factor to the relevance of robots arises due to the history of BBPLs. BBPLs such as the Lego MINDSTORMS language include support for robotics and its applications, meaning the field could be considered to be entangled with these languages [31]. Another contributor to this history is that, when excluding robots from BBPL research, one will inevitably make a continuous link with possible applications to robotics due to the nature and logic of robots, which is supported by BBPLs [31].

1.4 Target Audience

The target audience for this paper involves contributors and creators of BBPLs with a focus on educational robotics fields. This paper specifically focuses on characteristics which contribute to the success and usability of BBPLs to ensure the retention of concepts and understanding within the intended target audience. This paper can also be utilized by educators within the field of early development and schooling to analyze which BBPLs could assist in the implementation of an educational program. The literature analysis focused on a target audience of children within elementary education, usually between ages four and sixteen. This target audience had little to no exposure with textual programming languages or BBPLs, and was at a level which allowed them to grasp the concept of sequentially ordered operations (on both a mathematical and logical level) [31].

1.5 Research Question

The question that this literature review aims to answer is the following:

What characteristics of block-based programming languages support children when learning robotics programming?

2 Methodology

The research methodology for this paper involved the aggregation of papers through a literature review, followed by a subsequent review of all papers in the form of a literature study to identify keywords that are related to characteristics of block-based programming languages. The aggregation of papers was performed based on the keywords given, which are ”block-based language,” ”block- based programming language,” ”programming,” ”educational,” ”robots,” ”properties,” and ”children.” This aggregated search was performed utilizing academic and industry databases, such as SCOPUS and the IEEE database, as well as open access databases and aggregators, such as Scholar and Researchgate. Papers which matched, or matched upon a variation of, the given keywords were placed within a database and stored. The analysis of the papers was based on a set of criteria. These criteria included, but were not limited to, the amount of citations, the analysis that paper had in relevance to early-development robotic programming, the clarity of the characteristics, and overall usefulness of the paper. A

3 complete overview of the block-based criterion are found in section 3. After the papers were filtered based on their usefulness to the identification of relevant block-based characteristics, they were comparatively analysed based on their usefulness to the educational aspect of BBPLs. If a paper provided a clear set of characteristics for BBPLs and investigated its effects on the development of programming abilities in children, it would be rated higher than a paper that did not. A paper which focused on BBPLs and their development would also be rated comparatively high, since this information assists in the identification of possible characteristics. The paper presents the findings of this literature review as a set of definitions and a list of aggregated characteristics for BBPLs. These characteristics can be seen as aspects that are defining for BBPLs and assisting them to teach children robotics programming. More information about the characteristics and their rating is given in the section 4.

3 Block-Based Programming Languages

The literature that was studied for this literature review util- ized a span of different terms to identify similar programming languages. It was found that terms like ”Graphical Program- ming Languages [43],” ”Visual Programming Languages [31],” and ”Block-Based Programming Languages” [56] were used to represent similar programming languages along the lines of Scratch and ScratchJr. This paper utilizes the term ”Block-Based Programming Lan- guages” to refer to the aforementioned group of programming Figure 1: A program in the block- languages. The programming languages covered in other re- based language Blockly search will be identified as BBPLs if they meet the require- ments we use to distinguish BBPLs from other programming languages. The literature review does not consider concerns with the distinction between the block-based programming environment and the BBPL. It is believed that the visual elements influence how users view the language and are therefore not considered separate in this paper. Both terms are given a broad interpretation throughout this paper and it can be said that a property of the environment, like the point-and-click functionality, is a property of the language. As different terms are used to represent similar programming languages, it is necessary to present a clear set of characteristics that a language has to have to be considered a BBPL. Programming languages that fall within the scope of this paper, have the following properties: • The language has an interface comprised of (virtual and/or physical) building blocks (figure 1). • Users construct programs by combining atomic or composed blocks of code • Code blocks can contain other blocks, e.g. parameters in function signatures or statements inside loops • The language follows a procedural programming paradigm. It is believed that the first and the last properties need more explanation to be well understood. The first property requires the language to have an user interface that represents blocks of code as building blocks that can be picked up. A virtual block can be picked up with a mouse or touch screen and a real block can be picked up with hands. The last property requires the language to follow a procedural paradigm, because we focus our research on robot programming. This usually follows

4 a procedural (sometimes also known as sequential) paradigm, as the robot is given step-by-step instructions. Giving an exact definition on what is considered a BBPL is difficult, and thus it is deemed fitting to provide a few examples of what is considered to be a BBPL. This might make it more clear as to which programming languages fall within the scope of this paper and which languages do not. Programming languages such as ”Blockly”, ”Scratch (Jr.)” and ”CHERP” fall within the scope of this paper. ”Epic’s Blueprints Visual Scripting”, ”Visual Logic” and ”Logo” are examples of visual programming languages that do not fall within the scope.

4 Characteristic Specifications

A programming language generally has a set of key attributes that are important in some way. These attributes will be called characteristics. In order to keep things organized and clear, a useful characteristic will be identified by the following properties. 1. Is it useful? - There are many characteristics in languages, some of which align with a goal - in this case the goal is: ”Does it help children learn robotics programming?”. An example of something that fails this requirement would be a ”Do it for me”-button that provides an immediate implementation of a desired program. Instead of that button actually helping teach children robotics programming, it arguably works against it since the children would not be doing any programming. 2. Is it successful? - Of the characteristics that remain, only some are actually being used and can possibly reach their goal of being useful. In some cases even if they are being used, they don’t reach success by not reaching the aforementioned goal. These characteristics are still interesting, but the fact that they go unused means that they do not support the central goal. For example, allowing the definition and creation of ”custom functions” that act as methods or classes in other programming languages will fail this category as they go unused while actually being an important part of programming. 3. How often is it mentioned? - A single success is not enough to decide whether a charac- teristic is actually successful. Hence, a larger amount of papers and data is needed to get a proper idea of the success of a characteristic. Note that these characteristics are still useful to take note of, they are just less supported in terms of the amount of sources. Given that a characteristic sufficiently fulfils these points, it can be argued that these are key attributes that can contribute to reaching the goal.

5 Block-Based Programming Language Characteristics

The characteristics mentioned in this chapter are those which have been found to satisfy the characteristics as defined in section 4. The characteristics are discussed in their respective subsections, explaining the characteristic and the associated research.

5.1 Providing a Tangible User Interface

The definition for what constitutes a BBPL has been defined in section 3. Nonetheless, there are still different types of interfaces that can be explored which allow for different ways in which a user can interact with the programming language. Traditional block-based programming seem to rely on

5 a graphical user interface (GUI), of which applications like Scratch [45], Blockly [19] and Alice [12] are examples. However, an entirely different type of interface is the tangible user interface (TUI), having a growing interest. Tangible interfaces can be defined as concrete, physical manipulatives that can directly impact a digital environment [47]. In general, manipulatives such as these - digital, having embedded or associated some kind of computational power - are designed and employed to expand the range of concepts that children can learn through direct manipulation with concepts previously considered too advanced for children [46]. They also provide ways to mitigate the impact of some conceptual hurdles that are faced by novice programmers - of which there are many [36]- by easing or even eliminating the process of learning the language syntax [25]. According to Peta Wyeth, these interfaces allow children to use physical components to construct computer programs, and they are therefore appealing because they provide children with physical learning experiences [58]. Wyeth distinguishes three different types of environments providing such an interface: one producing tangible output (e.g. robotics programming), one requiring tangible input (i.e. using physical components to construct a program) and one in which both input and output are tangible. Although some empirical studies involve applications in which the input was exclusively tangible - such as the study by Horn and Jacob in 2007 [26] - most of the interest seems to be in applications of tangible interfaces revolving around robotics programming and therefore inherently concerning environments in which both input and output are tangible [6, 18, 25, 34, 47, 48, 50, 51, 52, 53, 58]. An example of such a programming environment is the Elec- tronic Blocks system created by Wyeth and Purchase at the University of Queensland in 2000 [34, 58]. It consists of stack- able Lego Duplo Primo blocks with embedded electronics, cat- egorized into three types: sensor blocks, logic blocks and action blocks (figure 2). Only two requirements are imposed on a valid program: each stack must include a sensor and an action block, and action blocks (smooth at the bottom) must be placed at the bottom. In an empirical study on this programming environment, Wyeth concluded that the tangible activity en- Figure 2: The ”Electronic Blocks” abled the successful learning of simple abstract programming tangible programming environment concepts [58]. [58]. Another example is Tern1), developed by Michael Horn at Tufts University. Early pioneering experiments exploring the value of tangible interfaces for robotics programming have worked with this language [18, 25]. Computer programs can be constructed by interlocking wooden blocks, each representing a flow-of-control construct, a parameter, or a sensor value (figure 3). The language uses a computer vision library (TopCodes) for the analogue-to-digital conversion necessary to parse the program. Based on this language a succeeding language named the Creative Hybrid Environment for Robotic Programming (CHERP)2) was created by the DevTech research group at Tufts University [13]. Beyond from the computer vision sup- Figure 3: The ”CHERP” tangible ported way of digitizing the program (allowing it to be used programming environment [47]. with for example LEGO Mindstorms RCX and LEGO WeDo robotics kits), this languages also supports scanning the blocks sequentially by using their bar codes (making it compatible with the KIWI robotics kit). It is important to note that the CHERP language is hybrid, a separating factor when comparing it to

1)http://hci.cs.tufts.edu/tern/ 2)https://ase.tufts.edu/DevTech/tangiblek/research/cherp.asp

6 language such as Electronic blocks. This term, hybrid, is used to refer to the same interactive system providing at least two or more equivalent interfaces [25]. A system with two equivalent interfaces is also said to have a bimodal interface [48]. In the literature about tangible interfaces for robotics programming this concerns languages that offer both a GUI and a TUI. Some interesting questions arise from this. Instead of just studying the effects of a tangible programming environment by itself, one might be interested what the advantages and disadvantages are of tangible environments when compared to graphical ones. Additionally, what would be the value of combining them into a bimodal interface? The study by Horn, Solovey, Crouser and Jacob in 2009 concludes that thoughtfully designed tangible interfaces can offer several significant advantages over traditional graphical equivalents: they can be more inviting, conducive to collaborative interaction, and better encourage children to take an active role in exploring and learning [27]. A later study by Horn, Crouser and Bers in 2012 claims that there are several advantages to the introduction of tangible interaction, and confirms that TUIs better invite active collaboration [25]. They state that a TUI can support young children with developing fine motor skills in those who are otherwise not able to participate in programming activities involving GUIs. This is due to the fact that GUIs require traditional human computer interaction styles with, for example, a mouse and keyboard or a touch screen for which young children might not have sufficiently developed the necessary motor skills. The researchers do acknowledge that there are features best left to GUIs, such as using a file system or specifying precise parameter values. A TUI also requires physical components and thus loses the advantages of, for example ease of deployment, a pure software system. There does not seem to be a clear consensus on whether hybrid interfaces (HUI) are advantageous. In the study by Strawhacker, Sullivan and Bers in 2013, results indicated that children using the TUI outperformed both the GUI and HUI groups [48]. One of the possible explanations offered is that the participants in the experiment might have been overwhelmed by the simultaneous introduction to the bimodal interface, impeding their ability to focus on learning the programming concepts that were tested for. This study does assume that the different types of interfaces are used simultaneously. On the other hand, the study by Horn, Crouser and Bers in 2012 suggests that a bimodal or even multi-modal (which is used to refer to interactive systems providing more than two equivalent interfaces) might support novice programmers with transitions between using different kinds of interfaces, an idea referred to as a tiered hybrid interface (e.g. from TUI to GUI, or eventually even to text-based interfaces) [25]. It is therefore concluded that providing a tangible interface can be considered an important part of a BBPL for robotics programming, since it lowers boundaries for children to start programming and can assist children in transitioning to GUIs or even text-based interfaces if used as part of a multi-modal interface.

5.2 Preventing Syntactic Errors Through Block Shape Constraints

The concept of syntax is a hard one: it can be unintuitive or frustrating for novice programmers such as children [18]. In order to avoid having to explain the concept of syntax and making it more intuitive, ideas are taken from jigsaw puzzles [50]. By combining the blocks the block-based programming language consists of with tabs and pockets - the shapes and cut-outs in a jigsaw puzzle - it becomes possible to display the limitations of the syntax of a program in a visual manner. Scratch and Blockly are prime examples that showcase this feature. The hybrid language described in section 5.1 - CHERP - also uses this characteristic [50]. This method can therefore be used in both tangible and intangible BBPLs. Many field tests have been done with scratch and in these field tests syntax does not seem to be an issue that is impeding the creation of programs [31, 41].

7 A good programming language for teaching programming in general helps greatly when you are teaching programming for robots. It is a feature that the most mentioned languages have, but it is also quite influenced by its implementation. The creators of Blockly noted that if shapes only looked connected but in fact were unconnected, a hidden syntax error occurs [19]. It is recommended that if the blocks, the puzzle pieces, are visually fitting together, that they are also actually connected. In the same paper [19] they also discuss the positive effect of a visual bug that occurred. If there is no more visual white space to place blocks in - in this case with C shaped blocks - the puzzle shape makes it less likely for children to place blocks inside the blocks. This was found to occur with if statements, but this is arguably also the case in others. We think that this could also apply to other kinds of blocks and shapes. This is a property that is present in the most used BBPLs, however small changes can have big impact as with the example of Blockly above. The visual impact goes beyond syntax and can affect how a language is used.

5.3 Drag-and-Drop or Point-and-Click

Research has been conducted on the effect of different mouse interaction styles on children’s performance with a variety of computer tasks, in particular the point-and-click interaction style (PaC) and the drag-and-drop interaction style (DnD) [1, 4, 17, 20, 24, 29]. Studies from Strommen [49] and Inkpen [28] conclude that PaC should be preferred over DnD. Children showed an inability to maintain consistent pressure on the mouse button for extended periods of time [49], which was supported by comments from children in which they complained about painful fingers [28]. Both studies also showed there would be less ’drop errors’, errors in which the wrong end point was clicked, when using PaC. Research from Barendregt and Bekker showed that most participating children initially applied DnD [4]. A study from Rietsma mentions that ”the increased risk of drop errors for children is generally considered to be the main reason to abandon the use of drag-and-drop in educational software.” [16], however another study from Rietsma claims that no distinguishing differences exist between the ’drop errors’ belonging to PaC and DnD [17]. Joiner et al. conclude that DnD brings more difficulty when using a mouse compared to PaC for young and older children with little or no experience in using a mouse [29]. It was found that after the age of 8 years, children with more experience using a computer did not show difficulties when using DnD. They suggest that ”children can overcome their earlier difficulties as their motor control increases with age and practice” [29]. Their research also showed that children of 5 and 6 years old had more difficulty using DnD than the older participants. They suggest that this could be because ”young children have difficulty controlling their limb movements which are necessary for controlling a computer mouse [29].” Aforementioned research seems to suggest that neither PaC or DnD should be preferred over one another. It should be pointed out that this research has been conducted by the use of a computer mouse, whereas nowadays tablets are widespread and can be used to replace the computer mouse. Research from Chang suggests that DnD on a touch-screen or mobile learning device still seem difficult for children around the age of 7 and 8 when using pen-based input. The results showed PaC to have a smaller mean reaction time than DnD [9]. Research from Vatuva, Cramariuc and Schipor draws the conclusion that small-age children have difficulties using DnD on a touch-screen surface [55].

8 Figure 4: Displaying multiple representations of a program in Blockly

During this literature study, it was found that many contradicting studies exist on whether PaC or DnD is better for children’s performance. It is not possible for a claim to be made that one interaction style should be used over the other, but the research does suggest that for children of young age PaC works better and that this difference disappears when children get older for both computer mice and touch-screen related input devices.

5.4 Displaying Multiple Program Representations

Certain programming concepts are easier to learn using visual block-based programming languages, so using a BBPL to learn them seems logical thing to do. Research has shown that children are better at interpreting conditional and boolean expressions if they learn it through the use of a visual BBPL when compared to a textual BBPL [38]. However, visual BBPLs become less ideal when programs start to scale up [8]. Non-visual textual programming languages (TPLs) are better for these purposes, but learning to program in a TPL is difficult [36]. Students find it difficult to learn general programming structure and how to design programs to solve certain tasks [36]. If children learn to program in a BBPL, then they can eventually move on to learning a TPL. To make the transition from block-based programming to textual programming easier the equivalent textual representation of the user’s program should be available at any time. A textual representation is independent of a certain TPL, so the program could be displayed in any desired language [30]. At the time of writing, Blocky supported displaying programs in Javascript, Python, PHP, Lua and Dart. By manipulating the block interface, the user can see the changes in the textual representation and see how the syntax changes when the program changes. Seeing the textual representation next to their own program makes the user more familiar with textual programming languages [30]. When the user is ready to start programming in the TPL, the block representation should be available to the user. Allowing the block representation to be available at any time allows the user to orient himself if he ever gets lost while writing the textual program. There are multiple programming languages that support this feature or that have been extended to support this feature. Languages that support it include RobotC [59], RCX SDK2 with MindScript [11], and the Blockly web editor (figure 4). Two of these languages are BBPLs specifically designed for programming robots.

9 5.5 Age Appropriate Content

Arithmetic and geometry are important concepts when you are programming robots. Robots commonly represent the world in a 2D or 3D Cartesian plane for which arithmetic and geometry are needed when you want to perform operations in this world. To move a robot, there needs to be calculations for the speed and the angles of limbs. This makes understanding of these concepts to a certain extent, necessary when programming robots. When children attend primary school, they do not immediately learn all mathematical concepts that are being used for programming. In the United States of America this is seen within the states that have adopted the Common Core State Standards. According to these standards, the Cartesian coordinate system is not taught until the 5th grade, negative numbers are not taught until the 6th grade, and also percentages are not taught until the 6th grade. There are BBPLs that have tried to solve the problem of age-appropriate content, such as Blockly and LaPlaya [24]. The latter one uses so-called ’increase/decrease by X’ blocks, which removes the need of understanding negative numbers [24]. It also uses ’set size to X’ blocks with the use of absolute amounts instead of percentages [24]. According to Gelderblom and Kotz´e,”children find it difficult to translate between the formal system of mathematics and the quantities, operations and concepts they represent” [20]. Introdu- cing concepts children do not even know could make it only harder for them to understand the programming language. We therefore recommend to take age appropriate content into account when developing/improving a BBPL for children to program robots.

6 Future Research

Not all programming, environmental, and learning problems have been solved by the characteristics of BBPLs. We would like to highlight some of these problems that have not yet been clearly solved by characteristics or aspects that are worth paying attention to. Many of the problems we will discuss are existing problems with programming languages and can be considered looking at when creating or improving BBPLs.

6.1 Teaching Methodologies for Block-Based Programming

According to Gomes [21] there are a lot of difficulties in the process of programming that one should take into account and we want to discuss some of them. For example, a lot of the times methodologies of teachers do not take into account the learning styles of students. Different students can have different preferences in the way they learn. A good aspect to think about for methodologies in BBPLs is how well they fit in the learning style of younger children. If certain concepts are taught at a younger age then the diversity of learning methods needed for students at a higher age might shrink. Giving the teacher the right idea on how to help children learn programming robots with the help of a BBPL could be a subject for future research. For example, one might make use of tutorials for or within BBPLs which form a guideline for teachers.

6.2 Including Children in the Programming Language Target Group

Apart from students having different learning styles there is also the complexity of programming languages that can have influence on the learning process. Programming languages can have very complex syntax which are defined for professional use and not with pedagogical motivations. In

10 the development of such programming languages the consideration of the developer could be that children are not in the target group. Because of this argument, the learning phase of programming languages might only be focussed on the learning capabilities of adults. While this is not crucial for every programming language it can be interesting to introduce a younger audience to important programming languages.

6.3 Interactive Programming Environment

Gomes [21] also suggests that there are a few solutions to overcome difficulties in programming like the ones aforementioned and we would like to highlight some of them. One of these solutions is that the use of programming patterns will help students. Programming patterns can be a visual window or view within the programming language and will show the student what he or she is doing wrong and can explain some examples of best practices. It has been shown that students would like to be shown example programs [36] and making use of this visual aspect in the environment could be helpful. Another very interesting solution is about the inclusion of games to stimulate children. We can also use the term ’gamification’ [14] here which suggests the use of aspects of games. Many BBPLs we have looked at already have a lot of aspects such as ”fun,” ”addictiveness,” or ”experience,” but we still think it would be interesting to consider gamification in future research or design.

6.4 Media in Programming Environments

We have seen some visual solutions, but there is also another concept that children already use a lot: digital media. There has been some research on this topic [39] and it very interesting to look at the concepts of digital media to use in BBPLs. A few examples that digital media can help younger children to learn are: mathematics, language and reading, cognitive skills and collaborate learning [39].

6.5 Complex Programming Paradigms

There are also some concrete problems within programming languages for university students [36]. Most important of these problems are recursion, pointers and error handling. This could suggest that it would perhaps be useful to prepare children at a younger age for these kinds of problems. A programming difficulty does not have to solved at once by children, but learning children problem solving methods step-by-step might help them overcome programming problems later on in their life.

6.6 Smells and Bugs

Finally, smells and bugs are also an important factor to deal with when coding. Children without much programming experience have a chance to create smelly code without knowing it. To highlight some important problems: frequent occurrences of smelly code are within the areas of duplicate code and lazy classes [22, 23]. An example of duplicate code in BBPLs is using multiple code blocks with the same function when there is already a code block which solves the same problem. ”Lazy classes,” classes which have almost no functionality left in them, can be represented in BBPLs as blocks with very few blocks attached to them, or blocks in which there is almost no code.

11 7 Limitations

The literary review found that there is a lot of breadth, but a limited amount of depth in the existing research. Many researchers did experiments with custom made BBPLs, but did not compare their languages with existing languages in experiments. This makes it harder to see what aspects are better compared to existing languages. Across the many studies there are many different ways experiments have been performed, which makes it harder to assess the effectiveness of said research compared to other research. While looking into the described BBPL aspects, it was found that most have been researched, but not experimented with. For example, the multiple representation aspect has been researched, but no research was found that did an experiment comparing two groups. One of these groups would program with only a BBPL and then learn a TPL, while the second group would see the textual representation while they were programming using the BBPL. The amount of studies that actually performed an experiment in a controlled fashion - using a control group and experiment group - was low. A paper comparing drag-and-drop and point-and-click that did perform a comparative study was found, but wasn’t reliable enough to use due to contradicting results and conclusions. More structured comparative research involving the effect of user interfaces on learning programming using BBPLs is needed. As in any literature research there were papers that we found that seemed useful at first sight, but unfortunately were not useful in the end. One of the papers in the review had been translated from Korean to English, but in the process had become incomprehensible, perhaps due to an automated translation. The paper mentioned in the previous paragraph seemed very interesting and had conducted their own research in which they compared different ways of interacting with a game. Eventually when we started looking at this paper more closely, we came across contradicting results and conclusions within the same paper. This left no choice but to reject anything this paper offered. Not only the papers that were not used had flaws, some of the used papers were not perfect either. The usage of ”Scaling Up Visual Programming Languages” by Burnett et al. [8] has been a point of discussion, because it describes problems with VPLs that are not always applicable to the BBPLs in the scope of this paper. It is believed, however, that some points, like screen real estate usage when compared to non-visual TPLs, do still hold for the considered BBPLs as well. Another paper that has some problems, is a paper written by Google Engineers [19]. In the paper, Google engineers describe what problems they ran into during the development of Blockly and what they learned from users’ experience. This paper has no references, thus it only uses its own data as source of truth without backup. It is believed that since it is written by the engineers who have built the language they discuss, this is not a very big problem. While writing this paper, it was difficult to make a clear distinction between concepts like VPLs and BBPLs. Some concepts have different names while they are the same and some concepts have no strict definition. Some BBPLs are visual, some are textual. Are BBPLs inseparable from their programming environments, or not? These are questions that are hard to answer, because of a lack of standards. There needs to be more research which might result in standards to make the distinction between concepts more clear and to allow universal terminology.

8 Conclusion

This paper provided a literature analysis which aims at identifying relevant characteristics for block-based programming languages with a focus on robotics education for young children. Based

12 on analysis of a keyword aggregation of relevant papers to the topic, a total of five major charac- teristics were identified which support an effective, child-focused, and robotics-aimed block-based programming language. The five characteristics which enhance the ability for children to program robots include: • the existence of a tangible user interface to lower the level of entry for children to utilize and program the language. • the existence of block shapes which enforce certain combinations of code, to ensure that syntactical errors are prevented. • the utilization of a drag-and-drop or a point-and-click interface, in which constraints are met per choice to ensure children have the motor skill capacity to utilize the interface. • multiple views of the program, including textual and logical diagrams of the block based equivalent, which enhances the understanding of textual syntax and methods for a beginning programmer. • age appropriate content, to make understanding the programming language not harder then it has to be. The analysis was also able to conclude that not all problems related to block-based programming languages have been solved. Although no conclusive evidence was found, the analysis found that papers focusing on the block-based programming languages all mentioned that positive impacts can be achieved when implementing characteristics similar to: • a high abstraction level, which places the focus of the implementation on solving a problem as opposed to syntactical rules. • the utilization of games to teach difficult concepts to children increases the accessibility. • the use of programming patterns allows a graspable constant to be identified by students when encountering unknown concepts. The aforementioned characteristics ensure, based on our research, that block-based programming languages are more accessible and graspable by young children when programming a robot with an educational focus. It also ensures an increased level of effectiveness.

9 Further Reading

This section presents a subset of research papers from the literature analysis that can provide additional reading on the topic of block-based programming languages for robotic development, and their impact on children and their effort to program the robots. • Barnes et al., Comparing Textual and Block Interfaces in a Novice Programming Environment [44] - Paper analyses the ability for students to grasp abstract programming concepts when comparing block-based implementations to identical implementation in textual languages. • Sullivan et al., The Wheels on the Bot go Round and Round: Robotics Curriculum in Pre-Kindergarten [50] - Paper provides a qualitative examination of three pre-kindergarten classrooms, totalling 37 students, and the impact of block-based programming languages on educational goals. Developed a language called ”Chirp,” a physical block based language. • Klassner et al., LEGO MindStorms: Not Just for K-12 Anymore [35] - Paper provides an insight into influential aspects for a block-based robotics language. The paper focusses on the application of LEGO Mindstorms, and new packages that can be utilized to develop extensions for the language.

13 • Hill et al., Floors and Flexibility: Designing a Programming Environment for 4Th-6th Grade Classrooms [24] - Paper provides an insight into developing a block-based programming lan- guage aimed at a specific age group, and a language that is not specific to robotics programming. Significant finding is that children are able to make links between new information and printed information between the fourth and eighth grade. • Weintrop et al., The challenges of studying blocks-based programming environments [56] - Paper which discusses the issues of analysing block-based programming languages, and splits these problems into four classes. Provides critique and a different view on block-based programming languages. • Wright et al., Writing, reading, watching: A task-based analysis and review of learners’ programming environments [57] - Paper which discusses and analyses the fundamental com- munication competencies (writing, reading, watching) and their impact on the ability to understand computer science concepts. • Horn et al., Comparing the use of tangible and graphical programming languages for informal science education [27] - Paper focuses on tangible user interfaces, and compares them to graphical user interfaces. Final conclusion addresses the impact of these characteristics on teaching children programming. • Kaui et al., Improving Introductory Programming with Scratch? [31] - Paper provides an in- depth analysis on aspects which assisted children in programming robots within the CEEBOT platform. • Bers, M., The TangibleK Robotics Program: Applied Computational Thinking for Young Children [6]- Paper focuses on design elements and skills required to actively involve and engage children within the field of educational robotics programming. Author is well-respected within the field. • Price et al., Comparing Textual and Block Interfaces in a Novice Programming Environment [44] - Case study paper which claims students are able to complete assignments faster when utilizing block based programming languages as opposed to textual languages.

14 References

[1] J. E. Agudo, H. Snchez, and M. Rico. Playing games on the screen: Adapting mouse interaction at early ages. In 2010 10th IEEE International Conference on Advanced Learning Technologies, pages 493--497, 2010. [2] M.P.-L.a Ana, J.G.-P.c Francisco, S.C.b Martn, and M.C.b Gonzlez. Developing computational thinking via the visual programming tool: Lego education wedo. 2016. [3] ASG Early Intervention Program. Feedback as a Teaching Strategy for Learning., 2012. [4] Wolmet Barendregt and Mathilde M. Bekker. Children may expect drag-and-drop instead of point-and-click. In CHI ’11 Extended Abstracts on Human Factors in Computing Systems, CHI EA ’11, pages 1297--1302, New York, NY, USA, 2011. ACM. [5] Valerie Barr and Chris Stephenson. Bringing computational thinking to k-12: What is involved and what is the role of the computer science education community? ACM Inroads, 2(1):48--54, 2011. [6] M. U. Bers. The tangiblek robotics program: Applied computational thinking for young children. Early Childhood Research & Practice, 12(2), 2010. [7] Marina Umaschi Bers, Louise Flannery, Elizabeth R Kazakoff, and Amanda Sullivan. Computa- tional thinking and tinkering: Exploration of an early childhood robotics curriculum. Computers & Education, 72:145--157, 2014. [8] Margaret M Burnett, Marla J Baker, Carisa Bohus, Paul Carlson, Sherry Yang, and Pieter Van Zee. Scaling up visual programming languages. Computer, 28(3):45--54, 1995. [9] C. K. Chang. Usability comparison of pen-based input for young children on mobile devices. In 2008 IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing (sutc 2008), pages 531--536, 2008. [10] D.H. Clements and D.F. Gullo. Effects of computer programming on young children’s cognition. 1984. [11] LEGO Company. http://lego.itam.mx/misc/software/firmware/RCX2_SDK_BETA/readme. txt, Jun 2000. [12] Stephen Cooper. The design of alice. Trans. Comput. Educ., 10(4):15:1--15:16, 2010. [13] Jordan Crouser and David Kiger. C.H.E.R.P. Technical Documentation, 2011. [14] S. Deterding, D. Dixon, R. Khaled, and L. Nacke. From game design elements to gamefulness: Defining ”gamification”. pages 9--15, 2011. cited By 870. [15] J. P. Diprose, B. A. MacDonald, and J. G. Hosking. Ruru: A spatial and interactive visual programming language for novice robot programming. In 2011 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pages 25--32. IEEE, 2011. [16] Afke Donker and Pieter Reitsma. Drag-and-drop errors in young children’s use of the mouse. Interacting with Computers, 19(2):257 -- 266, 2007. {HCI} Issues in Computer Games. [17] Afke Donker and Pieter Reitsma. Young children’s ability to use a computer mouse. Computers & Education, 48(4):602 -- 617, 2007. [18] Louise P. Flannery, Elizabeth R. Kazakoff, Paula. Bonta, Brian. Silverman, Marina U. Bers, and Mitchel Resnick. Designing scratchjr: Support for early childhood learning through computer programming. 2013. [19] Neil Fraser. Ten things we’ve learned from blockly. 2015.

15 [20] Hel´eneGelderblom and Paula Kotz´e. Ten design lessons from the literature on child development and children’s use of technology. In Proceedings of the 8th International Conference on Interaction Design and Children, IDC ’09, pages 52--60, New York, NY, USA, 2009. ACM. [21] A. Gomes and A.J. Mendes. An environment to improve programming education. University of Coimbra, 6 2007. [22] Felienne Hermans and Efthimia Aivaloglou. Do code smells hamper novice programming? 2016. [23] Felienne Hermans, Kathryn T. Stolee, and David Hoepelman. Smells in block-based program- ming languages. 2016. [24] Charlotte Hill, Hilary A. Dwyer, Tim Martinez, Danielle Harlow, and Diana Franklin. Floors and flexibility: Designing a programming environment for 4th-6th grade classrooms. In Proceedings of the 46th ACM Technical Symposium on Computer Science Education, SIGCSE ’15, pages 546--551, New York, NY, USA, 2015. ACM. [25] Michael S. Horn, R. Jordan Crouser, and Marina U. Bers. Tangible interaction and learning: the case for a hybrid approach. Personal and Ubiquitous Computing, 16(4):379--389, 2012. [26] Michael S Horn and Robert JK Jacob. Tangible programming in the classroom with tern. In CHI’07 extended abstracts on Human factors in computing systems, pages 1965--1970. ACM, 2007. [27] Michael S Horn, Erin Treacy Solovey, R Jordan Crouser, and Robert JK Jacob. Comparing the use of tangible and graphical programming languages for informal science education. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 975--984. ACM, 2009. [28] Kori M. Inkpen. Drag-and-drop versus point-and-click mouse interaction styles for children. ACM Trans. Comput.-Hum. Interact., 8(1):1--33, 2001. [29] R Joiner, D Messer, P Light, and K Littleton. It is best to point for young children: a comparison of children’s pointing and dragging. Computers in Human Behavior, 14(3):513 -- 529, 1998. [30] I.a Jung, J.b Choi, I.-J.b Kim, and C.c Choi. Interactive learning environment for practical programming language based on web service. 2016. [31] B. Kaui and T. Asi. Improving introductory programming with scratch? In 2011 Proceedings of the 34th International Convention MIPRO, pages 1095--1100. IEEE, July 2011. [32] Elizabeth Kazakoff and Marina Bers. Programming in a robotics context in the kindergarten classroom: The impact on sequencing skills. Journal of Educational Multimedia and Hypermedia, 21(4):371--391, 2012. [33] Elizabeth R Kazakoff and Marina Umaschi Bers. Put your robot in, put your robot out: Sequencing through programming robots in early childhood. Journal of Educational Computing Research, 50(4):553--573, 2014. [34] Caitlin Kelleher and Randy Pausch. Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers. ACM Comput. Surv., 37(2):83--137, 2005. [35] Frank Klassner and Scott D. Anderson. Lego mindstorms not just for k-12 anymore. 2003. [36] Essi Lahtinen, Kirsti Ala-Mutka, and Hannu-Matti J¨arvinen.A study of the difficulties of novice programmers. SIGCSE Bull., 37(3):14--18, 2005.

16 [37] Irene Lee, Fred Martin, Jill Denner, Bob Coulter, Walter Allan, Jeri Erickson, Joyce Malyn- Smith, and Linda Werner. Computational thinking for youth in practice. ACM Inroads, 2(1):32--37, 2011. Found using other paper from Bers. [38] Colleen M. Lewis. How programming environment shapes perception, learning and goals: Logo vs. scratch. In Proceedings of the 41st ACM Technical Symposium on Computer Science Education, SIGCSE ’10, pages 346--350, New York, NY, USA, 2010. ACM. [39] D.A. Lieberman, C.H. Bates, and J. So. Young children’s learning with digital media. 2009. [40] Adams Nager and Robert D. Atkinson. The case for improving u.s. computer science education. Information Technology & Innovation Foundation, 2016(8), 8 2016. [41] Kylie Peppler, Yasmin Kafai, Mitchel Resnick, and Natalie Rusk. Programming by choice: urban youth learning programming with scratch. 2008. [42] Dylan J Portelance and Marina Umaschi Bers. Code and tell: Assessing young children’s learning of computational thinking using peer video interviews with scratchjr. In Proceedings of the 14th International Conference on Interaction Design and Children, pages 271--274. ACM, 2015. [43] Dylan J. Portelance, Amanda L. Strawhacker, and Marina Umaschi Bers. Constructing the scratchjr programming language in the early childhood classroom. International Journal of Technology and Design Education, 26(4):489--504, 2016. [44] Thomas W. Price and Tiffany Barnes. Comparing textual and block interfaces in a novice programming environment. 2015. [45] Mitchel Resnick, John Maloney, Andrs Monro-Hernndez, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, and Yasmin Kafai. Scratch: Programming for all. 2009. [46] Mitchel Resnick, Fred Martin, Robert Berg, Rick Borovoy, Vanessa Colella, Kwin Kramer, and Brian Silverman. Digital manipulatives: new toys to think with. 1998. [47] Amanda Strawhacker and Marina U. Bers. ‘‘i want my robot to look for food’’: Comparing kindergartner’s programming comprehension using tangible, graphic, and hybrid user interfaces. International Journal of Technology and Design Education, 25(3):293--319, 2015. [48] Amanda Strawhacker, Amanda Sullivan, and Marina Umaschi Bers. Tui, gui, hui: Is a bimodal interface truly worth the sum of its parts? In Proceedings of the 12th International Conference on Interaction Design and Children, IDC ’13, pages 309--312, New York, NY, USA, 2013. ACM. [49] Erik Strommen. Children’s use of mouse-based interfaces to control virtual travel. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’94, pages 405--410, New York, NY, USA, 1994. ACM. [50] A. Sullivan, E. R. Kazakoff, and M. U. Bers. The wheels on the bot go round and round: Robotics curriculum in pre-kindergarten. Journal of Information Technology Education: Innovations in Practice, 12:203--219, 2013. [51] Amanda Sullivan, Marina U. Bers, and Elizabeth R. Kazakoff. The effect of a classroom-based intensive robotics and programming workshop on sequencing ability in early childhood. 2012. [52] Amanda Sullivan and Marina Umaschi Bers. Robotics in the early childhood classroom: learning outcomes from an 8-week robotics curriculum in pre-kindergarten through second grade. 2016. [53] Amanda Sullivan, Mollie Elkin, and Marina Umaschi Bers. Kibo robot demo: Engaging young children in programming and engineering. In Proceedings of the 14th International Conference on Interaction Design and Children, IDC ’15, pages 418--421, New York, NY, USA, 2015. ACM.

17 [54] David S. Touretzky, Daniela Marghitu, Stephanie Ludi, Debra Bernstein, and Lijun Ni. Accelerating k-12 computational thinking using scaffolding, staging, and abstraction. In Proceeding of the 44th ACM Technical Symposium on Computer Science Education, SIGCSE ’13, pages 609--614, New York, NY, USA, 2013. ACM. [55] Radu-Daniel Vatavu, Gabriel Cramariuc, and Doina Maria Schipor. Touch interaction for children aged 3 to 6 years: Experimental findings and relationship to motor skills. International Journal of Human-Computer Studies, 74:54 -- 76, 2015. [56] D. Werntrop and U. Wilensky. The challenges of studying blocks-based programming en- vironments. In 2015 IEEE Blocks and Beyond Workshop (Blocks and Beyond), pages 5--7, 2015. [57] T. Wright and A. Cockburn. Writing, reading, watching: A task-based analysis and review of learners’ programming environments. pages 167--170, 2000. cited By 5. [58] Peta Wyeth. How young children learn to program with sensor, action, and logic blocks. Journal of the Learning Sciences, 17(4):517--550, 2008. [59] Raghavender Goud Yadagiri, Sai Prasanth Krishnamoorthy, and Vikram Kapila. A blocks-based visual environment to teach robot-programming to k-12 students. 2015.

18