Conference PaperPDF Available

Automatic Detection of Bad Programming Habits in Scratch: A Preliminary Study

Authors:

Abstract and Figures

Using the Scratch environment as a tool to teach programming skills or develop computational thinking is increasingly common in all levels of education, well-documented case studies from primary school to university can be found. However, there are reports that indicate that students learning to program in this environment show certain habits that are contrary to the basic programming recommendations. In our work as instructors with high school students, we have detected these and other bad practices, such as the repetition of code and object naming, on a regular basis. This paper focuses on verifying whether these issues can generally be found in the Scratch community, by analyzing a large number of projects available on the Scratch community website. To test this hypothesis, we downloaded 100 projects and analyzed them with two plug-ins we developed to automatically detect these bad practices. The plug-ins extend the functionality of the Hairball tool, a static code analyzer for Scratch projects. The results obtained show that, in general, projects in the repository also incur in the investigated malpractices. Along with suggestions for future work, some ideas that might assist to address such situations are proposed in the conclusions of the paper.
Content may be subject to copyright.
Automatic Detection of Bad Programming Habits in
Scratch: A Preliminary Study
Jes´
us Moreno
Programamos.es & Instituto Nacional de
Tecnolog´
ıas Educativas y de Formaci´
on del Profesorado
Madrid, Spain
jesus.moreno@programamos.es
Gregorio Robles
GSyC/LibreSoft
Universidad Rey Juan Carlos
Madrid, Spain
grex@gsyc.urjc.es
Abstract—Using the Scratch environment as a tool to teach
programming skills or develop computational thinking is increas-
ingly common in all levels of education, well-documented case
studies from primary school to university can be found.
However, there are reports that indicate that students learning
to program in this environment show certain habits that are
contrary to the basic programming recommendations. In our
work as instructors with high school students, we have detected
these and other bad practices, such as the repetition of code
and object naming, on a regular basis. This paper focuses on
verifying whether these issues can generally be found in the
Scratch community, by analyzing a large number of projects
available on the Scratch community website.
To test this hypothesis, we downloaded 100 projects and
analyzed them with two plug-ins we developed to automatically
detect these bad practices. The plug-ins extend the functionality
of the Hairball tool, a static code analyzer for Scratch projects.
The results obtained show that, in general, projects in the
repository also incur in the investigated malpractices. Along with
suggestions for future work, some ideas that might assist to
address such situations are proposed in the conclusions of the
paper.
Keywords— Scratch; programming; bad habits; learning; auto-
matic assessment; Scratch repository; empirical analysis
DIS CL AI ME R
This document is a draft. The published paper can be
accessed at IEEExplore1.
I. INTRODUCTION
Scratch [10] is a programming environment including a
visual programming language designed for children over 6
years old, a development environment and a website where the
community can host their projects, run, study and reuse other
programs, and share ideas or suggestions with other program-
mers. Although there are several similar visual programming
languages, Scratch is undoubtedly the most successful one
with more than three million registered users in its website
and more than five million shared projects in its repository2.
Scratch is being used both in extracurricular activities [4]
or summer camps [1], as in elementary schools [13], high
schools [9] and even universities worldwide [5]. Its capacity
to bring computer programming to children and teenagers
1http://goo.gl/j5uWqN
2See http://scratch.mit.edu/statistics/
with the aim of fostering computational thinking abilities
and to promote ICT studies, and its success to teach both
basic and advanced programming concepts (concepts such as
user interaction, conditional statements, communication and
synchronization, logical expressions and data representation
are taught) has been well documented [7], [3], [15].
However, it is also possible to find studies that have detected
some bad programming habits in students learning to program
in this environment [8]. In this line, in our work as instructors
we have also found some bad habits despite having insisted
our students to avoid them. As these habits are contrary to
the basic programming recommendations, our study tries to
find out if they are also common in the projects shared in the
Scratch repository.
The goal of this paper, therefore, is to determine whether
these bad habits are common practices in the Scratch com-
munity in an automatic manner and propose some ideas to
try to avoid such situations. In order to assist evaluators to
detect these malpractices we have developed two plug-ins that
automate the detection of the bad programming practices by
extending the functionality of Hairball, a static code analyzer
of Scratch projects.
The structure of this paper is as follows: In section II a
brief overview of Scratch is presented, including some research
studies that have investigated learning in this environment
and other studies that automate the evaluation of learning.
In section III our work methodology is briefly described.
Section IV presents the results we have obtained from applying
our methodology on a small sample of Scratch projects.
Finally, Section V contains the conclusions of our study and
some ideas and suggestions for future work are discussed.
II. BAC KG ROUND
Scratch is a visual programming environment, developed by
the Lifelong Kindergarten group at the MIT Media Laboratory,
that allows to program interactive projects using a drag-and-
drop approach with different pieces or Lego style blocks [10].
Scratch was designed with the main goal of encouraging young
people to program, and most of its users are novice learners
with no prior programming experience [6]. The environment is
designed to encourage users to manipulate and modify various
media types, so that children and teenagers can create projects
that they find interesting and attractive, such as animated
stories, games or interactive presentations [7].
Scratch also offers a website where the projects programmed
by the community are published. The code of programs hosted
there can be run, and following the community idea of the free
software movement it can be studied and analyzed. So, it is
possible to make suggestions and to reuse the code, and there
are lots of valuable resources available for anyone willing to
start to program. This approach offers as well the opportunity
to learn social skills related to programming and beyond, such
as sharing and contributing to the community [11].
Despite the positive impact of Scratch, Meerbaum-Salant,
Armoni and Ben-Ari [8] prove that students learning to
program in this environment show some bad habits that are
contrary to recommended programming practices. In partic-
ular, they show a tendency to excessive decomposition and
a bottom-up development process, starting with individual
blocks of Scratch.
Aiming to simplify the process of evaluating computational
thinking and help evaluators with an automatic tool, Hairball
was created [2]. Hairball is a static analyzer of Scratch projects
inspired by Lint3that tries to detect programming errors in
Scratch projects, such as not initializing the value of a variable
or the state of a character, sending messages that are not
received by any program, including code that is never run,
among others.
III. METHODOLOGY
In our work as instructors with high school students, we
found that, despite our constant insistence and warnings, many
students show on a regular basis two bad habits that have to
do with object naming and code repetition:
1) Students do not change the names of the characters,
which are automatically named by the environment as
SpriteX where X is an incremental number. When the
amount of characters in a project is large, it becomes
very hard to know what object relates to a given state-
ment, contributing to poor code readability, slowing the
project programming, and complicating debugging to fix
bugs.
2) Students repeat code in the same project, sometimes
even in the same character programs. Thus, abstrac-
tion and modularization, two key components of the
development of computational thinking [14], are not
trained. And the code base becomes more complicated
to maintain and update in the future.
In order to detect these two behaviors in Scratch projects
automatically, we have developed following plug-ins for the
Hairball environment [2], which in turn make use of kurt4, a
library implemented in Python. The developed plug-ins are:
1) convention.SpriteNaming5analyzes a Scratch project to
check if the names of its characters begin with the string
3http://www.unix.com/man-page/FreeBSD/1/lint
4https://github.com/blob8108/kurt
5https://github.com/jemole/hairball/blob/master/hairball/plugins/
convention.py
Fig. 1. Sprites with default names
Sprite, indicative for the user not having changed the
default name.
As an example to illustrate the drawbacks associated
with this bad programming behavior, Fig. 1 shows a
script that is difficult to read because the complete
character area has to be explored to find what character
refers to a particular block. This makes the program
difficult to debug should errors arise, making it hard to
improve the code and slowing down the programming
tasks.
2) duplicate.DuplicateScripts6analyzes a Scratch project
to try to locate repeated complete programs within a
project. In order to do so, the plug-in runs each script
of the project and gets the tokens of the different blocks
of the programs, so that two blocks that only differ in
the values they receive are considered to be equal. A
minimum length of five blocks is applied for programs
to be considered duplicate rather than coincidentally
similar.
To illustrate the operation of this plug-in, Fig. 2 shows
two scripts containing the same blocks with the only
difference of the values received by parameter.
The Scratch scripts are analyzed by the plug-in and
translated into tokens. The analysis would result in con-
6https://github.com/jemole/hairball/blob/master/hairball/plugins/duplicate.
py
Fig. 2. Two scripts repeating code
Fig. 3. Definition of blocks to avoid code repetition.
sidering them equal, as their code would be translated
in both cases into the following sequence of tokens:
’set rotation style %s’
’repeat %s%s’
’move %s steps’
’next costume’
’if on edge, bounce’
’wait %s secs’
Hence, the correct way to implement this functionality
would have been as shown in Fig. 3, defining a new set
of blocks that receives several values per parameter, and
then reusing the block created in both programs. This
solution would facilitate future maintenance, updating
and debugging.
In order to test the functionality of the developed plug-ins
and to verify whether these behaviors are common in projects
found in the Scratch repository, we proceeded to randomly
download 100 projects from the repository. As the possibility
for users to define their own blocks, using def block feature,
is only available since the release of Scratch 2.0, we selected
and downloaded projects created for this version. A replication
package of the projects under study, and the specific version
of the plug-ins used in it can be obtained publicly7.
IV. FINDINGS
The results obtained after analyzing the 100 projects confirm
that observations made with our students can also be generally
found in the community projects, as shown in Table I.
7http://gsyc.urjc.es/grex/repro/2014-fie-scratch
Default names Duplicated scripts Blocks defined
Projects 79 62 17
Mean 5.94 7.23 1.11
Median 3 2 0
Maximum 67 71 25
TABLE I
TABL E OF R ESU LTS
Regarding the lack of habit of renaming the characters
and not using the default name assigned by the environment,
79% of the analyzed projects contained at least one non-
renamed SpriteX character. The maximum number of non-
renamed SpriteXs found has been 67, which makes the code
very hard to maintain (i.e., one could consider this almost as
code obfuscation). In mean, almost 6 SpriteXs can be found
in a project, while the median is 3. Our results show that this
is a severe problem in the analyzed projects in Scratch, as in
addition to the fact that re-naming occurs in very few projects,
the number of elements used in the others are significant in
number; being those programs are very hard to understand, its
maintenance and reuse are hindered.
As for the repetition code, 62% of the analyzed projects
contained at least one repeated program. In fact, only 17% of
the analyzed projects made use of block def block to define
its own blocks that can be reused in other parts of the project.
The mean of duplicated scripts and blocks defined provides us
insight about how difficult is for the authors of the analyzed
projects to use abstraction and modularization: duplicated code
appears over six times more than blocks.
V. CONCLUSIONS AND FURTHER RESEARCH
This paper shows the preliminary results of a study regard-
ing two bad programming habits we have detected in our work
as instructors with high school students learning to program
with Scratch. In order to check if these bad habits, which
have to do with object naming and code repetition, are also
commonly found in the projects shared in the community
repository, we downloaded 100 projects and analyzed them
with two plug-ins we developed for Hairball, detecting that
most of the inspected projects, 79% and 62% respectively,
fall into these issues.
Regarding object naming, it is worth to note that Scratch
users name the variables used in their projects correctly, i.e.,
semantically meaningful. In our opinion the reason to explain
this paradox is because it is mandatory to assign a name to a
variable the moment it is created, as the environment does not
name it by default. However, when creating a new character a
SpriteX name is assigned automatically. In our views, a change
of this feature of the environment, forcing users to name new
objects, might eliminate this bad practice.
Regarding code repetition and the low usage Scratch users
make of the possibility of creating their own blocks (the equiv-
alent of defining methods or procedures in other languages),
works as the one performed by Seiter and Foreman [12], in
which they show that abstraction and modularization capacities
are concepts that seem to be developed from a certain age,
may explain the low rates of use of this functionality, since a
significant part of the Scratch community consists of children
under 10 years8. Future studies should further investigate
how to continue advancing in the definition of an appropriate
framework for different ages, as well as to check whether users
learning online and those who do it in a regulated environment
show different use rates of this functionality.
In the near future we plan to extend the scope of our study
developing new plug-ins to automate the detection of other
issues, such as the degree of development of computational
thinking demonstrated in a project, and by analyzing a much
larger number of projects to achieve more accurate conclu-
sions. In this sense, the release of a research dataset with
the first five years of data from the Scratch repository9will
be certainly a great help to our work. Finally, we are in the
process of developing a website that will allow students to
receive immediate feedback for their programs with warnings
of potential errors and tips to improve their code.
ACK NOWLED GM EN TS
The work of Gregorio Robles has been funded in part by
the Spanish Government under project SobreSale (TIN2011-
28110) and under project “eMadrid - Investigaci´
on y Desar-
rollo de tecnolog´
ıas para el e-learning en la Comunidad de
Madrid” (S2009/TIC-1650) funded by the Region of Madrid.
REFERENCES
[1] J. C. Adams. Scratching middle schoolers’ creative itch. In Proceedings
of the 41st ACM technical symposium on Computer science education,
pages 356–360. ACM, 2010.
[2] B. Boe, C. Hill, M. Len, G. Dreschler, P. Conrad, and D. Franklin.
Hairball: Lint-inspired static analysis of scratch projects. In Proceeding
of the 44th ACM technical symposium on Computer science education,
pages 215–220. ACM, 2013.
[3] D. Franklin, P. Conrad, B. Boe, K. Nilsen, C. Hill, M. Len, G. Dreschler,
G. Aldana, P. Almeida-Tanaka, B. Kiefer, et al. Assessment of computer
science learning in a scratch-based outreach program. In Proceeding of
the 44th ACM technical symposium on Computer science education,
pages 371–376. ACM, 2013.
[4] Y. B. Kafai, D. A. Fields, and W. Q. Burke. Entering the clubhouse:
Case studies of young programmers joining the online scratch commu-
nities. Journal of Organizational and End User Computing (JOEUC),
22(2):21–35, 2010.
[5] D. J. Malan and H. H. Leitner. Scratch for budding computer scientists.
ACM SIGCSE Bulletin, 39(1):223–227, 2007.
[6] J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond. The
scratch programming language and environment. ACM Transactions on
Computing Education (TOCE), 10(4):16, 2010.
[7] J. H. Maloney, K. Peppler, Y. Kafai, M. Resnick, and N. Rusk. Pro-
gramming by choice: urban youth learning programming with scratch.
ACM SIGCSE Bulletin, 40(1):367–371, 2008.
[8] O. Meerbaum-Salant, M. Armoni, and M. Ben-Ari. Habits of program-
ming in scratch. In Proceedings of the 16th annual joint conference on
Innovation and technology in computer science education, pages 168–
172. ACM, 2011.
[9] O. Meerbaum-Salant, M. Armoni, and M. Ben-Ari. Learning computer
science concepts with scratch. Computer Science Education, 23(3):239–
264, 2013.
[10] M. Resnick, J. Maloney, A. Monroy-Hern´
andez, N. Rusk, E. Eastmond,
K. Brennan, A. Millner, E. Rosenbaum, J. Silver, B. Silverman, et al.
Scratch: programming for all. Communications of the ACM, 52(11):60–
67, 2009.
8http://scratch.mit.edu/statistics/#age
9https://sites.google.com/site/scratchdatameeting/
[11] C. Scaffidi and C. Chambers. Skill progression demonstrated by users
in the scratch animation environment. International Journal of Human-
Computer Interaction, 28(6):383–398, 2012.
[12] L. Seiter and B. Foreman. Modeling the learning progressions of
computational thinking of primary grade students. In Proceedings of the
ninth annual international ACM conference on International computing
education research, pages 59–66. ACM, 2013.
[13] A. Wilson, T. Hainey, and T. Connolly. Evaluation of computer
games developed by primary school children to gauge understanding of
programming concepts. In 6th European Conference on Games-based
Learning (ECGBL), pages 4–5, 2012.
[14] J. M. Wing. Computational thinking and thinking about computing.
Philosophical Transactions of the Royal Society A: Mathematical, Phys-
ical and Engineering Sciences, 366(1881):3717–3725, 2008.
[15] U. Wolz, H. H. Leitner, D. J. Malan, and J. Maloney. Starting with
scratch in cs 1. ACM SIGCSE Bulletin, 41(1):2–3, 2009.
... They analysed 100 Scratch projects downloaded from Scratch community repository and found out that in many projects the default objects names assigned by the environment were used. Also, above half of analysed applications had at least one repeated block of code (Moreno and Robles, 2014). ...
... It brings new possibilities but also can generate some problems. The language has many limitations (lack of procedures, not supporting data structures), can preserve bad programming habits (Moreno and Robles, 2014). However, it easiness of access (usage) and versatility causes that it is worth to add the elements of visual programming to the IT courses especially for non-technical students, also for business students who in the future will be analysts, data scientists so the employees that would need some algorithmic skills or knowledge of IT tools to create analytical models. ...
... However, basic programming knowledge should be possessed by future analyst, knowledge engineers, data scientists that will have to use and develop specialised analytical models, or prepare tools for robotic process automation. Disadvantages of the Scratch environment reported by Harvey and Mönig (2009) and Moreno and Robles (2014) are important problems, however, they are of minimal importance when the course is basic level and it attendants had no previous experiences in the area of computer applications programming. So, it is worth to add the elements of visual programming to the IT courses for non-technical university students. ...
Article
Digital nations have become dependent on computer applications. One of the most important part of literacy in todays digital word are the basics of computer applications usage and development. Programming seems to be quite difficult to learn, therefore, several educational programming environments and programming languages were developed, so that more people could create the applications. Modern technologies mean that computer programming is not a skill reserved only for a small group of specialists with extensive knowledge of mathematics, algorithms and computer design. Nowadays, programmers can become people of different ages and interests, therefore, basic computer programming courses should be offered for various groups of students. The article addresses the problem of basic programming courses for non-computer science students. The aim of the paper is to present the role of visual programming languages in encouraging university students to create algorithms and start programming. The article presents the characteristic of Scratch, the framework of course for logistics students. Contains also students opinions (n=119) about learning the basics of programming with Scratch. The research allows to conclude that Scratch is very easy to access and to use. It makes introduction to programming more enjoyable, helps to concentrate on the problem and the business process. Logistics students notice the benefits of visual programming languages and would like to attend basic programing classes. Students acquired knowledge and skills mainly performing instructions received from the teacher and watching video tutorials. The comparative analysis showed also differences between groups of students. The contribution of the study can be both empirical (tested course syllabus) and methodological (how to teach new generations of IT developers and data scientists).
... Con lo anterior se pretende atender ciertas limitaciones planteadas sobre la programación con bloques, específicamente con Scratch, permitiendo a los estudiantes definir sus propios bloques, lo que les faculta para personalizar códigos complejos en un bloque reutilizable aunque los estudiantes a menudo no usan los bloques definidos por el usuario (Moreno y Robles, 2014). ...
Book
Full-text available
Este libro de investigación, es producto de la participación de diferentes integrantes vinculados a semilleros y grupos de investigación ubicados en el contexto regional, nacional e internacional tales como: GOMATECIN, CIEDUS, Ciencias del Lenguaje, Pedagogía infantil, Educar 2030, Laboratorio de Enseñanza, Historia y Filosofía de la Biología (UFBA), Competências Profissionais e Produção de Conhecimento na Contemporaneidade (COMPORTI), CRIDI, y el Laboratorio de Neurociencia (LabNEC-UFPA); cuyos intereses están relacionados con la tecnología desde el campo social y educativo. Se resalta igualmente, la participación de investigadores de la Universidad Santiago de Cali, la Institución Universitaria Escuela Nacional del Deporte, Universidad del Valle, Universidad del Cauca, Universidad Pedagógica Nacional, Universidad Pontificia Bolivariana, Universidad Nacional Abierta y a Distancia (UNAD), Universidade Federal do Pará, Universidade Federal da Bahia, Universidad Federal de São Carlos, Universidad Andina y Universidade Licungo.
... Con lo anterior se pretende atender ciertas limitaciones planteadas sobre la programación con bloques, específicamente con Scratch, permitiendo a los estudiantes definir sus propios bloques, lo que les faculta para personalizar códigos complejos en un bloque reutilizable aunque los estudiantes a menudo no usan los bloques definidos por el usuario (Moreno y Robles, 2014). ...
... However, some studies showed that using VPLs has certain disadvantages. These include extremely fine-grain programming (EFGP) in the form of spaghetti code and bottomup development [31], students do not change the character names, and abstraction and modularization are not trained, which are two key components of computational thinking [32]. Furthermore, students struggle with understanding one of the basic programming conceptsvariables and obtain an incomplete understanding of expressions and operators [33]. ...
Article
Novices enrolled in introductory programming courses often face many difficulties. These difficulties are more emphasized when novices are K–12 students. Many new visual programming languages have primarily been designed to provide a smooth introduction to programming for children. However, at some point, a general‐purpose text‐based programming language should be used. A well‐known and studied method is to visualize program execution to assist novices in forming correct mental models. Although many studies have investigated the effects of using visualizations in teaching and learning, most of them focus on courses taught at the university level. Studies that focus on investigating the impact of program visualizations at the K–12 level are, to the best of our knowledge, scarce. Therefore, we investigated the impact of using program visualizations with a group of K–12 students. Because of the underrepresentation of girls in computer science and known gender stereotypes, we additionally investigated student performance based on gender. Our research included 98 fifth‐grade students from three elementary schools. The lectures in the experimental group included different visualization techniques, including a program visualization tool and PowerPoint animations, whereas the control group had no program visualizations. All students learned Python as part of their curriculum. We present the results of our research in this paper.
... While simulation-based work is one option, there can also be value in designing an offline executable environment for students to develop and test their algorithms before they implement them on physical robots. Finally, an automated grading or feedback generation system [15,18] would be a useful supplement to our current selection of example projects and rubrics, both to reduce the load on teachers and to detect bad programming habits. ...
Article
Für die Programmierung von Industrierobotern hat jeder Hersteller seine eigene Sprache entwickelt. Zwar stellen alle diese Sprachen einen ähnlichen Funktionsumfang bereit, der Wechsel des Herstellers erfordert aber meist die Neuentwicklung des Programmes. Diese Programmierung ist häufig textbasiert und erfordert einen hohen Einarbeitungsaufwand. In dieser Arbeit stellen wir ein Framework vor, das eine graphische Programmierung ermöglicht und Programme für unterschiedliche Hersteller generiert.**
Thesis
Full-text available
In this study, the effect of homogeneous and heterogeneous pairing, in terms of individual differences, in pair programming on group compatibility, flow and coding performance were investigated. In line with this purpose, seven individual difference cases, such as "gender, learning style, friendship, extraversion and conscientiousness components of personality traits, coding self-efficacy, and coding prior-knowledge" were determined to be used for pairing in pair programming. This study, designed as a mixed study, is a multiple case one. In the quantitative part of the study, posttest only nonequivalent control group design was used. During the fall semester of 2018-2019 academic year, 64 voluntary 3rd and 4th year undergraduate students enrolled in the elective "Information Management Applications" course at the department of CEIT of a large state university. As a result of the study, high levels of group compatibility and flow, but middle-level of coding performance were reached in all individual difference cases irrespective of group's being homogeneous or heterogeneous. Besides, it was concluded that the homogeneous group experienced higher level flow in the learning style case. In the friendship case, homogeneous group experienced higher level flow, while heterogeneous group showed higher level coding performance. It was also seen that the heterogeneous group exhibited a higher level of coding performance in the case of conscientiousness component of personality traits. Students prefer to pair as homogeneous or heterogeneous by friendship and coding prior-knowledge level in pair programming due to various reasons. In addition, they prefer to pair the ones with high task-related conscientiousness. Participant students expect to achieve higher group compatibility, flow, and coding performance in this way. In this context, in order to increase the flow experience in pair programming, it may be suggested to create homogeneous groups by the learning style and friendship, and to create heterogeneous groups by conscientiousness component of personality traits and friendship.
Article
Full-text available
Το ενδιαφέρον για την Υπολογιστική Σκέψη (ΥΣ) αυξάνεται παγκοσμίως τα τελευταία χρόνια. Παρότι δημιουργείται υλικό για την ανάπτυξή της και προτείνονται προσεγγίσεις για την αξιολόγησή της, δεν υπάρχει ακόμα κοινά αποδεκτός ορισμός. Η αξιολόγηση της ΥΣ αποτελεί απαραίτητη προϋπόθεση για την επιτυχή εισαγωγή της σε προγράμματα σπουδών. Το άρθρο αυτό αποτελεί μια επισκόπηση των ερευνών που έχουν γίνει τα τελευταία χρόνια για την αξιολόγηση της ΥΣ. Οι έρευνες που μελετήθηκαν, ανάλογα με την προσέγγιση που χρησιμοποιούν, κατηγοριοποιήθηκαν σε τρεις ομάδες: α) αξιολόγηση της ΥΣ σε συγκεκριμένα προγραμματιστικά περιβάλλοντα, β) με κριτήρια αξιολόγησης ΥΣ και/ή ψυχομετρικά εργαλεία, και γ) με πολλαπλές μεθόδους αξιολόγησης της ΥΣ. Τα κυριότερα προβλήματα στην αξιολόγηση της ΥΣ είναι η αδυναμία κάλυψης όλων των εννοιών κι ηλικιών των μαθητών και η σχετική ανεπάρκεια των εργαλείων να αξιολογήσουν αυτόνομα κι επαρκώς την ΥΣ. Από τη βιβλιογραφία προκύπτουν προτάσεις για αξιολόγηση της ΥΣ, ενώ η χρήση πολλαπλών μεθόδων αξιολόγησης συνεχίζει να είναι η πλέον ενδεδειγμένη και έγκυρη προσέγγιση.
Article
Full-text available
This paper describes Scratch, a visual, block-based programming language designed to facilitate media manipulation for novice programmers. We report on the Scratch programming experiences of urban youth ages 8-18 at a Computer Clubhouse 'an after school center' over an 18-month period. Our analyses of 536 Scratch projects collected during this time documents the learning of key programming concepts even in the absence of instructional interventions or experienced mentors. We discuss the motivations of urban youth who choose to program in Scratch rather than using one of the many other software packages available to them and the implications for introducing programming at after school settings in underserved communities.
Article
Full-text available
Scratch is a visual programming environment that allows users (primarily ages 8 to 16) to learn computer programming while working on personally meaningful projects such as animated stories and games. A key design goal of Scratch is to support self-directed learning through tinkering and collaboration with peers. This article explores how the Scratch programming language and environment support this goal.
Conference Paper
Full-text available
Each July since 2003, the author has directed summer camps that introduce middle school boys and girls to the basic ideas of computer programming. Prior to 2009, the author used Alice 2.0 to introduce object-based computing. In 2009, the author decided to offer these camps using Scratch, primarily to engage repeat campers but also for variety. This paper provides a detailed overview of this outreach, and documents its success at providing middle school girls with a positive, engaging computing experience. It also discusses the merits of Alice and Scratch for such outreach efforts; and the use of these visually oriented programs by students with disabilities, including blind students.
Article
Scratch is a visual programming environment that is widely used by young people. We investigated if Scratch can be used to teach concepts of computer science (CS). We developed learning materials for middle-school students that were designed according to the constructionist philosophy of Scratch and evaluated them in a few schools during two years. Tests were constructed based upon a novel combination of the revised Bloom taxonomy and the Structure of the Observed Learning Scratch is a visual programming environment that is widely used by young people. We investigated if Scratch can be used to teach concepts of computer science (CS). We developed learning materials for middle-school students that were designed according to the constructionist philosophy of Scratch and evaluated them in a few schools during two years. Tests were constructed based upon a novel combination of the revised Bloom taxonomy and the Structure of the Observed Learning Outcome taxonomy. These instruments were augmented with qualitative tools, such as observations and interviews. The results showed that students could successfully learn important concepts of CS, although there were problems with some concepts such as repeated execution, variables, and concurrency. We believe that these problems can be overcome by modifications to the teaching process that we suggest. Outcome taxonomy. These instruments were augmented with qualitative tools, such as observations and interviews. The results showed that students could successfully learn important concepts of CS, although there were problems with some concepts such as repeated execution, variables, and concurrency. We believe that these problems can be overcome by modifications to the teaching process that we suggest.
Article
Under the Curriculum for Excellence (CfE) in Scotland, newer approaches such as games-based learning and games-based construction are being adopted to motivate and engage students. Construction of computer games is seen by some to be a highly motivational and practical approach at engaging children at Primary Education (PE) level in computer programming concepts. Games-based learning (GBL) and gamesbased construction both suffer from a dearth of empirical evidence supporting their validity as teaching and learning approaches. To address this issue, this paper will present the findings of observational research at PE level using Scratch as a tool to develop computer games using rudimentary programming concepts. A list of criteria will be compiled for reviewing the implementation of each participant to gauge the level of programming proficiency demonstrated. The study will review 29 games from Primary 4 to Primary 7 level and will present the overall results and results for each individual year. This study will contribute to the empirical evidence in gamesbased construction by providing the results of observational research across different levels of PE and will provide pedagogical guidelines for assessing programming ability using a games-based construction approach.
Conference Paper
We introduce the Progression of Early Computational Thinking (PECT) Model, a framework for understanding and assessing computational thinking in the primary grades (Grades 1 to 6). The model synthesizes measurable evidence from student work with broader, more abstract coding design patterns, which are then mapped onto computational thinking concepts. We present the results of a pilot-test study of the PECT Model in order to demonstrate its potential efficacy in detecting both differences in computational thinking among students of various ages as well as any clear overall progressions in increasing computational sophistication. Results of this sort are vital for establishing research-based and age-appropriate curricula for students in the primary grades, i.e., developing non-trivial, challenging but not overly daunting lesson plans that utilize the cognitive development stage of each grade level most effectively.
Conference Paper
Many institutions have created and deployed outreach programs for middle school students with the goal of increasing the number and diversity of students who later pursue careers in computer science. While these programs have been shown to increase interest in computer science, there has been less work on showing whether participants learn computer science content. We address two questions, one specific, and the other more general: (1) "What computer science did our middle school students learn in our interdisciplinary two-week summer camp?" (2) "How can computer science concepts be assessed in the context of Scratch-based outreach programs"? We address both questions by presenting the design of our summer camp, an overview of our curriculum, our assessment methodology, and our assessment results. Though the sample size is not statistically significant, the results show that a two-week, interdisciplinary, non-academic summer camp can be effective not only for engaging students, but also for imparting CS content. In just two weeks, with a curriculum not entirely focused on computer science, students displayed competence with event-driven programming, initialization of state, message passing, and say/sound synchronization. We have employed assessment methodologies that avoid written exams, an approach both outreach and classroom-based programs may find useful.
Conference Paper
Scratch programming has risen in prominence, not only as a potential language for K-12 computer science, but also in introductory college courses. Unfortunately, grading Scratch programs is time-consuming, requiring manual execution of each program. Automation of this process is greatly complicated by the very reason Scratch is an attractive introductory language--the projects are multimedia in nature, requiring eyes and ears to fully appreciate. We propose Hairball, an automated system that can be used both by a student to point out potential errors or unsafe practices, and by a grader to assist in inspecting the implementation of Scratch programs. Because automatic analysis will not be able to determine the sensory effect, Hairball focuses instead on the implementation, including safe/robust programming practices, providing a "lint-like" tool for Scratch. In this case study, we have created an initial set of Hairball plugins that detect and label instances of initialization of Scratch state, synchronization between say and sound blocks, synchronization between broadcast and receive blocks, and use of timing and loops for complex animation. Our evaluation shows that Hairball is very useful in conjunction with manual analysis. Overall, Hairball was actually slightly more accurate than manual analysis at labeling these instances. Specifically for broadcast/receive, Hairball's analysis correctly classified 99% of the 432 instances, manual analysis only 81%. Overall, if Hairball was only used to identify correctly implemented instances, with manual analysis for the remainder, it would remove 76% of the instances for the manual analysis and assist in the rest, with a false positive rate of less than 0.5%.
Article
The Scratch environment exemplifies a tool+community approach to teaching elementary programming skills, as it includes a website where users can publish, discuss, and organize animations that are programs. To explore this environment's effectiveness for helping people to develop programming skills, a quantitative analysis of 250 randomly selected users' data, including more than 1,000 of their animations, was performed. Skill based on 4 models that had proven useful in prior empirical studies was measured. Overall, mixed results about the environment's effectiveness were found. Among users who do not drop out, an increasing progression in social skills was found. However, an extremely high drop-out rate was also observed. Moreover, a flat or decreasing level of demonstrated skill was observed on virtually every measure. These results call into question whether simply combining an animation tool and an online community is sufficient for keeping people engaged long enough to learn elementary programming skills.
Conference Paper
Over the last 45 years as a student and faculty member in Computer Science, I have been involved in learning, teaching, and writing for the CS1 course. I have authored or co-authored textbooks for CS1 in nine different programming languages from Fortran ...