Embed Size (px)
Citation preview
Teaching Programming and Language Concepts Using LEGOs®
Cynthia S. HoodIllinois Institute of Technology
10 W. 31st St.Chicago, IL 60616
1.312.567.3918
Dennis J. HoodCinaptus
2668 Salix CircleNaperville, IL 60564
1.630.579.4508
ABSTRACTIn this paper we describe an innovative method for using LEGO® bricks to teach programming and other computing concepts. LEGO® bricks are used to express a special purpose language to build creations out of LEGOs. Using this language, students can execute and create programs. Both fundamental and more advanced concepts can be taught. The use of LEGOs increases the tactile and kinesthetic aspects of the learning experience and helps to make abstract concepts more concrete. We have used this method to teach a variety of concepts to college freshmen, K-12 teachers, and K-12 students.
Categories and Subject DescriptorsD.3.3 [Programming Languages]: Language Classifications– Specialized application languages. K.3.2 [Computers and Education]: Computer and Information Science Education– Computer science education.
General TermsLanguages
KeywordsSpecial purpose language, LEGO®, programming concepts, language design
1. INTRODUCTIONComputer Science concepts tend to be taught primarily using lecture and computer lab format. In this paper we describe an innovative method for using LEGO® bricks to teach programming and other computing concepts. LEGO® bricks are used to express a special purpose language to build creations out of LEGOs®. Using this language, students can execute and create programs. Both fundamental and more advanced concepts can be taught. The use of LEGOs® increases the tactile and kinesthetic aspects of the learning experience and helps to make abstract concepts more concrete. We have used this method to teach a variety of concepts to college freshmen, K-12 teachers, and K-12 students.
A variety of different kinds of languages have been used to teach programming to different audiences. The use of mini-languages as a pedagogical tool for teaching programming and language concepts is described in [3]. Visual programming languages such as [4] have been proposed to teach novice programmers more advanced concepts. Although LEGO® MINDSTORMS™ are currently being used as a tool to teach many different computing concepts [1], [2], [5], we are unaware of anyone who has used a language developed out of LEGO® bricks .
This paper begins with a specification of the language in section 2. Section 3 describes how the language was used in teaching diverse audiences along with observations. A discussion of general observations and future work is included in Section 4.
2. LANGUAGE SPECIFICATIONThe goal of the language is to be able to build LEGO® creations on a standard grid baseplate (see Figure 1). We began with a tub of one thousand assorted LEGO® bricks. The tub contained approximately twenty different types of bricks in ten different colors. To build a creation brick by brick it is necessary to specify the type of brick, its color and its location on the baseplate. The language is specified using colored 1x1 bricks where the combination of colors and positions indicates a specific action. By executing a series of instructions, or program, a number (one for each instruction) of LEGO® bricks are positioned on the baseplate, thereby building the desired creation.
Figure 1. Standard 32x32 grid baseplate with 32 rows of bumps and 32 columns of bumps.
2.1 Version 1The first version of the language limits the type of building bricks to square 2x2 blocks. Since there are ten different colored 2x2 bricks, each instruction must specify the color of the brick along with its location. The location is specified using x,y coordinates.
Therefore ten distinct colors or color combinations are needed to identify the color of the brick and thirty-two distinct colors or color combinations are needed to identify both the column and row (i.e. x and y coordinates). This information can be represented with two or more colors of 1x1 bricks. Each brick represents c combinations, where c is the number of different colored bricks. The size or total number of bricks in each instruction is a function of the amount of information that needs to be conveyed, the number of combinations that can be specified, and the number of colored 1x1 bricks available. We arbitrarily chose to use six different colored 1x1 bricks. Therefore, the total number of bricks for a single instruction is six; two for the color of the square brick to be placed on the baseplate, two for the x-coordinate of the brick, and two for the y-coordinate of the brick. Figure 2 shows an example instruction.
Figure 2. Example instruction comprised of six 1x1 bricks.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
ITiCSE’054, June 27–29, 2005, Monte de Caparica, Portugal.Copyright 2005 ACM 1-59593-024-8/05/0006…$5.00.
• • • • • •
This example instruction is decoded as follows. The first two bricks indicate the color of the 2x2 brick to be placed on the baseplate, in this case the blue,blue combination indicates a blue brick. The third and fourth bricks indicate the column or x-coordinate and in this case the red, black combination indicates row one (see Figure 3).
Figure 3. Mapping of color combinations to x,y coordinates.
The fifth and sixth bricks specify the row or y-coordinate and in this case the red, green combination indicates row three. Therefore this instruction places a blue, 2x2 brick at (1,3) on the baseplate. This means that the bump on the lower left-hand corner of the brick should be aligned with the bump at the specified location and the brick should be pressed into place. If there is already a brick at this location, the new brick should be placed on top of the existing brick.
2.1.1 LimitationsFor simplicity, version 1 is limited to 2x2 bricks for building. Since there is only a single kind of brick used, the type is implicit and does not need to be specified. The use of square bricks also eliminates the need to specify the orientation of the brick on the baseplate. This language also assumes that creations are built from the bottom up. Bricks can be placed on top of other bricks, but there is no ability to connect a brick from underneath. The cost of the reduction in complexity is a loss of creative freedom and aesthetics in the design of a LEGO® creation.
2.2 Version 2The second version of the language was developed to allow for use of different types of bricks. The types of bricks to be used are illustrated in Figure 4. With non-square bricks, orientation needs to be considered. For simplicity, the orientation of the bricks is restricted to be as shown in Figure 4.
Figure 4. Examples of different size bricks.
Now the language needs to specify the type of brick, the color, and the position. As before, six different colors of 1x1 bricks are used to specify the instructions. Since there are forty brick types and color combinations (ten different colors), three bricks are necessary to specify this information. For simplicity, the instruction size is kept at six bricks by limiting the number of colors to six. With a more complex specification, up to nine colors and thirty-six brick types and color combinations could be conveyed with this number of bricks. Color choice was reduced to maintain ease of decoding.
In Version 2 of the language, the color of the first brick indicates the type of brick to place, either 1x2, 2x2, 3x2 or 4x2. The color of the second brick indicates the color of the brick to be placed. The remaining four bricks in our six-brick instruction design indicate the position on the baseplate at which the referenced brick should be placed. As in Version 1, the color combination of bricks three and four indicate the X position, or column, while the color combination of bricks five and six indicate the Y position or row. As in Version 1, the bump on the lower left-hand corner of the LEGO® (as oriented in Figure 4) should be aligned with the bump at the specified position and the brick should be pressed into place. If there is already a brick at this location, the new brick should be placed on top of the existing brick.
Figure 5 shows a program and the resulting creation. The program is on the right-hand side of the baseplate. To execute the program one starts by decoding each instruction to place a brick in the proper position on the baseplate. In this language there is one instruction for each brick that is part of the design.
• • =0 • • =11 • • =22
• • =1 • • =12 • • =23
• • =2 • • =13 • • =24
• • =3 • • =14 • • =25
• • =4 • • =15 • • =26
• • =5 • • =16 • • =27
• • =6 • • =17 • • =28
• • =7 • • =18 • • =29
• • =8 • • =19 • • =30
• • =9 • • =20 • • =31
• • =10 • • =21
Figure 5. Example of a program and the resulting creation.
2.2.1 LimitationsFor simplicity, the language constrains the type of brick, colors and brick orientation. This limits the types of creations that can be designed using the language. The brick type and color constraints can be handled by providing only the allowed bricks for building. The orientation constraint is more problematic. The designer must keep the orientation in mind when building. As described in Section 3.1.2, improper orientation was a source of program errors. In addition, as in Version 1, all creations must be built from the bottom up. Although this could also cause problems, the issue would be identified when the design was coded and the creation could be redesigned appropriately.
3. USE OF LANGUAGEThese languages have been used to teach a variety of topics to different audiences. Originally the language was invented to teach freshmen CS majors about language design. It was then used to teach two separate groups of K-12 students about programming and program execution. One of the groups was 5 th
graders and the other was a group of high-school students. Finally, the language was used to introduce K-12 teachers to programming and program execution. In each group the use of the language provided opportunities to discuss more abstract concepts. The details of the exercises developed and the experiences with different groups are described below.
3.1 CPU SimulationTo begin with, the operation of the central processing unit (CPU) of a computer is described. More specifically, the fetch, decode and execute cycle is detailed. After some discussion of these concepts, the students then get to be the CPU. They are given a program1, a baseplate, a set of bricks for building, and the instructions for decoding the language as specified above in Section 2. The students are to simulate the CPU and execute the given program to build a LEGO® creation.
The students generally worked together in groups of two or three. Groups in close proximity were given different programs to ensure each worked independently. Originally the programs
1 The program may be placed on the same baseplate used to build the creation as in Figure 5, a separate baseplate, or it may be freestanding.
were designed to be freestanding. The 1x1 bricks can build on each other along with 6x1 bricks at the top and bottom of the program. These physical programs tend to become unstable as the program length grows. This coupled with the problem of the programs breaking when dropped resulted in the more stable physical realization of the programs on the baseplate.
3.1.1 Experiences with CS FreshmenThis exercise was done with CS freshmen late in their first semester using Version 1 of the language. They quickly got the hang of executing the program to build the LEGO® creations. Most of the groups divided the tasks with one student decoding the brick colors and physically fetching the bricks and the other student decoding the location. They also identified patterns in the programs and utilized them to their advantage, thereby reducing processing time. This prompted a discussion about processor look-ahead and caching.
The freshmen used the original specification of the language that was specified in words only (i.e. red,red = 0, red,black=1, etc.) instead of the type of pictorial representation shown in Figure 3. This did not appear to be an issue. Additionally, the baseplate axes were not originally numbered so the students had to count bumps each time they were placing a brick. Based on student feedback, the baseplate axes were numbered.
3.1.2 Experiences with K-12 StudentsThe next group to try this exercise was a group of twenty 5 th
grade students. The programs were built using Version 2 of the language and the language was expressed pictorially. We met with these students for only thirty minutes at a time. After a very short introduction to CPU operation, the students began working on executing the programs. All of the programs were designed to build alphabetic letters.
Two of the ten groups understood the exercise immediately and built their creations without any help. The remaining groups needed some help in understanding how to decode the program. Within thirty minutes, eight of the ten groups had built their creations. One of the groups that did not finish had incorrectly
Figure 6. 5th grade students working on decoding program.
Figure 7. 5th grade students showing off program creation.oriented a brick causing some confusion and the other group had not gotten the hang of the exercise. Figures 6 and 7 show the 5 th
grade students working on this exercise.
The group of high-school students also used Version 2 of the language and the pictorial expression of the language. These students were given a variety of complex programs. With minimal assistance, the students were able to build the creations. Again the students recognized and took advantage of the patterns they saw in the programs.
3.1.3 Experiences with K-12 TeachersTwo different groups of K-12 teachers tried this exercise. One was a small group of six middle-school science teachers participating in an NSF-sponsored program on science inquiry, and the other was a group of twenty-two teachers from a variety of grade levels and subject areas. The teachers used Version 2 of the language with the pictorial expression of the decoding rules.
Until this point, everyone who tried this exercise was excited about working with LEGOs®. All of the students had some familiarity with how the bricks fit together to build creations. In contrast, some of the teachers had never used LEGOs® and some had never even seen them. The assumption that using LEGOs® made this material more accessible was challenged. It took some time for the teachers to get used to building with the bricks. The teachers were generally more hesitant than the other audiences. They tended to take more time to do the exercise. It appeared to take them longer to get comfortable with the decoding, but once they did they began to recognize and utilize patterns.
3.2 Writing and Testing ProgramsOnce the task of executing a program was mastered, the students were instructed to build something on the baseplate using ten to twenty LEGO® bricks. Once each group had their creation built, they used the 1x1 bricks to formulate the program for building their creation instruction by instruction. At this point we discussed the importance of the sequence of the instructions. We talked about situations where order is critical (e.g. bricks built upon other bricks) as well as those where it does not matter (e.g. bricks placed directly onto the baseplate).
After the programs were coded, the students were encouraged to test their own code. The next step was to exchange programs with another group to test each others code by executing the code to build the LEGO® creation. We tried to keep groups from seeing each others creations to maintain the integrity of the testing process.
When errors occurred, students were charged with determining whether the error was in the code (programmer error) or due to faulty decoding/execution of the instruction (CPU error). This step proved to be very interesting as both sides (programming and processing) typically defended their work passionately until detailed analysis of the instructions identified the source of the error and thereby the guilty party. The certainty and passion motivated the teams to eagerly and deliberately examine the code making the topic of debugging far easier to discuss than we had anticipated.
3.2.1 Experiences with CS FreshmenMany of the programs had errors. Recall that this group used Version 1 of the language. There were a variety of programmer and CPU errors. Some errors such as invalid brick color combination, invalid location coordinate, and specified brick unavailable prevented the instruction from being executed. A specific brick might be unavailable for example when the entire supply of a green 2x2 bricks is currently being used by other groups. The identification of different types of errors prompted an interesting discussion of compiler error checking. On the other hand, CPU errors could generally only be detected once the entire program was executed.
3.2.2 Experiences with K-12 StudentsThis group was introduced to the debugging process. We talked to them about the kinds of possible errors and encouraged the two groups to work together to find the source of the errors. With this audience we also brainstormed about real computer errors they had encountered. Returning to the initial discussion about the CPU, we talked about how CPU errors are possible, but much less likely than programming or software errors. We stressed that computers can only do what they are told or programmed to do and do not think on their own.
3.2.3 Experiences with K-12 TeachersThe discussion with the teachers was very similar to the one with the K-12 students described above. In addition, we had a discussion about the need for and use of higher-level languages. Many of the teachers were aware of various higher-level languages such as Visual Basic and HTML along with tools for building programs using these languages. In particular, many were familiar with web-page building tools such as FrontPage and Dreamweaver.
We took the opportunity to compare and contrast the use of one of these tools with direct HTML programming. We discussed the pros and cons of designing at different levels of abstraction. The tradeoff between the ease of learning and use and the level of control over the design was discussed. Many of the teachers had done some work with web pages and had some familiarity with the tools. We showed the HTML code behind a webpage to give a feel for the level of abstraction. We contrasted this with the LEGO® language and compared that to manipulating each pixel independently. We discussed how the LEGO® language is a kind of low-level machine language. When programming or executing the LEGO® language, the teachers were struck by the repetitive nature of the task.
At this point the difference between high- and low-level languages was becoming clearer to the teachers. We took this opportunity to introduce the concept of the compiler. After
doing tedious and error-prone programming, the teachers appreciated the need for and value of compilers. At the teachers’ request, as an offshoot of this exercise we introduced some material about the history of computing with particular focus on the contributions of women. We discussed the ENIAC programmers and Grace Hopper’s development of the compiler. After their programming experience, this material prompted a lively discussion and much interest.
3.3 Extending the Programming LanguageThe last part of the exercise was to challenge the students to think about design issues involved in extending the language. This part was only done by the CS freshmen due primarily to time constraints with the other groups. The student groups were given a bucket of one thousand bricks containing approximately twenty different types of bricks in ten different colors. The assignment was to extend Version 1 of the language so that all of the types and colors of bricks could be used to build creations. The students had to think about the tradeoffs involved in language design.
One approach is to calculate the maximum number of combinations of bricks, colors and orientations and increase the instruction size to accommodate all of the possible combinations. This is where most of the students started. We then discussed the overhead involved in storing and processing each instruction. We discussed ways to make the languages more efficient. With this the semester and exercise ended.
4. OBSERVATIONSIn general, people seem to really enjoy working with LEGOs® as a means of exploring programming and processing concepts. For the first time all semester, the CS freshmen were all truly engaged in the same exercise. The 5 th graders and high school students were very comfortable and therefore very creative with the bricks. The adults were a bit more apprehensive, but even those who had not used LEGOs® before quickly eased into the exercise and gained a good understand of the technical concepts as a result.
The use of LEGOs® seemed to level the playing field since none of the participants had ever done this type of activity before. Since the method was new for everyone, even those who had no programming experience were comfortable exploring the concepts.
A significant benefit of this approach is that it uses no technology at all, and is therefore extremely low-cost and easy to implement. It may seem ironic that this “technology free” approach appears to be very effective in helping participants deeply explore these sophisticated technology concepts. We however believe that it is largely because of the absence of technology, which can be intimidating, that this approach has shown such promise consistently across a diverse audience.
Informal assessment of these exercises has been positive particularly with the CS freshmen. Seventy-five percent of the
course evaluations included positive comments about the LEGO exercises such as, “more LEGO exercises”.
4.1 Future WorkWe plan to expand this approach to more deeply explore the design of programming languages and even more sophisticated topics such as parallel processing.
We are currently exploring partnerships with assessment specialists to help us develop quantitative aptitude progress methods.
We are also expanding the lesson to put more emphasis on higher-level language issues including compilers and algorithms.
5. ACKNOWLEDGEMENTSSincere thanks to Helene Caliva for inspiring us to think creatively and inviting us to try our methods with her 5 th grade enrichment classes.
6. REFERENCES[1] Barnes, D.J. Teaching introductory Java through LEGO
MINDSTORMS models. ACM SIGCSE Bulletin, Proceedings of the 33rd SIGCSE technical symposium on Computer Science Education, 34, 1, 2002, 147-151
[2] Garcia, M.A. and Patterson Mc-Neill, H. Learning how to Develop Software Using the Toy LEGO MINDSTORMS. ACM SIGCSE Bulletin, Proceedings of the 7th annual Conference on Innovation and Technology in Computer Science Education, 34, 3, 2002, 239.
[3] Klassner, F. A Case Study of LEGO MINDSTORMS’ suitability for Artificial Intelligence and Robotics Courses at the College Level, In Proceedings of the 33rd SIGCSE technical symposium on Computer Science Education, 2002, 8-12.
[4] Ledgard, H.F. Ten Mini-Languages: A Study of Topical Issues in Programming Languages. ACM Computing Surveys., 3, 3 (Sept. 1971), 115-146.
[5] Materson, T.F and Meyer, R. M.SIVIL: A True Visual Programming Language for Students. In Proceedings of the sixth annual CCSC Northeastern Conference on the Journal of Computing in Small Colleges. Middlebury, VT, 2001, 74-86.
