Eple thesis

University of Cagliari
Faculty of Mathematics, Physics
and Natural Sciences

Master of Science in Information Technology

An Interactive Environment
for the Didactical Manipulation
of Programs

Supervisor Candidate
Riccardo Scateni Pier Giuliano Nioi

Examiner
Andrea Casanova

Academic Year 2011-2012

Title:
An Interactive Environment for the Didactical Manipulation of
Programs

Author:
Pier Giuliano Nioi

Supervisor:
Riccardo Scateni

Examiner:
Andrea Casanova

Thesis typology:
Experimental

Abstract:
In the process of getting novices learning computer programming
is necessary to ease the process by using the right tools and avoid to
clutter novices mind with too many not-so-important details con-
cerning structure and characteristics of a particular language, and
instead letting them to be able to grasp the fundamental abstract
concept of programming. In this work we will go through the pro-
cess of building an interactive novice learning environment that suits
those needs of learning.

Keywords:
Learning Environment, Teaching Tools, Program Simulation, Pro-
gram Manipulation, Web Application, CS1, Python, Program Visu-
alization

This part of tree
has become book
in April 2013.
May one day
after completing its cycle
among men desirous of knowledge
return to Earth
and become a new tree.

Contents

1 Introduction 3
1.1 About this work . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Goals of this work . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Sequence of activities . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Chapters overview . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Learning Environments 7
2.1 History and state of the art . . . . . . . . . . . . . . . . . . . 7
2.2 Examples of Learning Environments . . . . . . . . . . . . . . 9
2.2.1 Not directly related to learning programming . . . . . 10
2.2.2 Directly related to learning programming . . . . . . . . 18

3 Learning Programming 27
3.1 Learnable Programming . . . . . . . . . . . . . . . . . . . . . 27
3.2 Where state of the art fails . . . . . . . . . . . . . . . . . . . . 39

4 Inventing Eple 45
4.1 Finding a solution to the problem . . . . . . . . . . . . . . . . 45
4.1.1 Conceptual prototyping . . . . . . . . . . . . . . . . . 47
4.2 Finding pre-existing solutions . . . . . . . . . . . . . . . . . . 51
4.2.1 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 Visualization . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3 Connecting the dots . . . . . . . . . . . . . . . . . . . 54

1

2 CONTENTS

5 Building Eple 57
5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1 Merging the parts . . . . . . . . . . . . . . . . . . . . . 58
5.1.2 Adding features . . . . . . . . . . . . . . . . . . . . . 59
5.1.3 Architectures . . . . . . . . . . . . . . . . . . . . . . . 60

6 Using Eple 63
6.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Functionalities overview . . . . . . . . . . . . . . . . . . . . . 65
6.3 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Pro and cons of EPLE . . . . . . . . . . . . . . . . . . . . . . 71

7 Conclusions 73
7.1 Work recap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1.1 Future works . . . . . . . . . . . . . . . . . . . . . . . 75

Chapter 1

Introduction

1.1 About this work
One of the most important things in education is to adjust the teaching
methods and tools to the nature of the content:

One size does not fit all.

In the teaching environment this rule is rarely applied. In fact, the opposite
rule, known as

One size fits all

is used with its counterproductive effects on students. As Papert [1] said,
what an individual can learn, and how he learns it, depends on what models
he has available. More models, more tools and thus more sizes of a curricu-
lum, meaning the more ways to learn he has available, the more the student
will be involved in what he’s learning. Understanding will be more deep and
personal with tools that promote experimenting with a custom made micro-
world for a specific topic, avoiding the need to solely memorizing things
without understanding them. These kind of thoughts put the spotlight upon
a topic that names like Montessori and Piaget already discussed in the last
century, but Papert ones are related to constructionism and learning theory
applied with computer technologies. In his work called “Mindstorms” Papert

3

4 CHAPTER 1. INTRODUCTION

takes those thoughts and concretize them with the creation of the Logo Lan-
guage and Turtle Graphics with Logo, a toolset that uses computer to teach
some really profound concepts of Math to young children. Instead of propos-
ing a classical curriculum, he proposed a micro-world with its rules, in this
case basic math rules, that made possible for a child the exploration of well
known real world concepts in math with the help of a physical and graphical
aid called Turtle, that a child can identify himself with. In conclusion he
created an appropriate tool for tackling the learning process of math from
another point of view, with great results.

Drawing inspiration from this example, in this thesis work we use the same
methodology of creating the right tools for the right job but targeting novice
programmers. In the process of getting novices learning computer program-
ming, is necessary to ease the process by using the right tools and avoid
to clutter novices mind with too many not-so-important details concerning
structure and characteristics of a particular language, and instead letting
them to be able to grasp the fundamental abstract concept of programming.
In this work we will go through the process of building an interactive novice
learning environment that suits those needs of learning, after analyzing what
the current tools used by novices are, and what are their limitations and
proposing a theoretical solution and a proof-of-concept implementation of an
interactive learning environment that can be used in introductory courses of
computer programming.

1.2 Goals of this work
Like mentioned above, the main goal of this work is to create a learning envi-
ronment that makes possible for novice computer programming students to
understand the inner workings of a computer program by showing, in an ab-
stract and useful way, the behavior of the fundamentals building blocks of all
common programming languages without focusing on any of them in partic-
ular, but staying as general as possible, in a pseudocode manner, and taking
care of hiding not-so-useful-at-the-moment details to the student to ease the

1.3. SEQUENCE OF ACTIVITIES 5

process of learning and thus giving easily digestible bits of information about
programming.

1.3 Sequence of activities
For the realization of this work, was followed this sequence of activities:

Studying the state of the art. Finding what has already been done in
our field of work and analyze their characteristics and limitations.

Studying and realizing a concept. Prototyping an interface for such a
tool and a relative software architecture to sustain the whole tool.

Researching pre-built software. Instead of reinventing the wheel, it is
important to continue the development from available software that can be
modified to our needs.

Studying and hacking pre-built software. Once the pieces of software
are found, starts the process of deeply studying them and hacking them to
find their potential.

Implementation of personal solution. Starts the “welding” process of
various pieces of software that originally weren’t made to talk one another,
and follows the implementation of unique features for the personal software
solution prototyped before.

1.4 Chapters overview
What follows is a short recap of the content of each chapter in this work.

In chapter 2, Learning Environments, we will talk about the concept of learn-
ing environments, what they are, where do they come from and show some

6 CHAPTER 1. INTRODUCTION

examples of various learning environments acting in various fields of knowl-
edge. We then move on to our specific field of interest, computer program-
ming, and analyze what learning environments are available at the moment
of writing.

In chapter 3, Learning Programming, we focus on what it means to build
such an environment that is suitable for teaching and learning purposes with
regard of programming, and with those concepts in mind we will then con-
tinue the analysis of the limits of the current available learning environments
and of the tools currently used for computer programming teaching and upon
those limitations.

In chapter 4, Inventing Eple, we will study and create a theoretical concept
of tool that may suit our needs. We then look for pre-existing software solu-
tion that can be used as starting point to our project and studying them for
subsequent process of making pieces of software talk to one another.

In chapter 5, Building Eple, is described the implementation phase with focus
on the technologies used in the process and the software architecture created
for the tool. Will be analyzed the structure of the tool, divided in frontend
and backend, and each component will be respectively analyzed.

In chapter 6, Using Eple, we will do an overview of functionalities of the
tool and analyze an example created with the tool, and the general benefits
introduced by the tool.

In chapter 7, Conclusions, we draw conclusions from the work done, and
show future developments of the tool that may be used or integrated in
bigger environments even outside the teaching and learning field.

Chapter 2

Learning Environments

In this chapter we are going to talk briefly about what Learning Environments
(L.E. from now on) are, what they try to accomplish and what are the most
popular examples in various fields of knowledge. We then focus on our field
of interest, that is programming learning, and analyze what is available and
where those solutions available meet their limits.

2.1 History and state of the art
As stated above at the beginning of the introductory chapter, names like
Montessori first and Piaget after, inspired the work of Seymour Papert of
building a so called L.E. for letting the children exploring the world of math
concepts for the first years of school. He followed theories like Construc-
tivism, which states that learning is an active and continuous process where
the learner takes information from the environment and constructs personal
interpretations and meaning based on prior knowledge and experience. Dur-
ing the learning process the learner faces curiosity and investigation of the
environment he has in front of himself, and experimenting with that envi-
ronment he develops interests and needs that have a great influence on the
learning process itself, making the learner more active and participant on the
entire process, and thus personal interpretations builds up to be the base of
next question and interests guided not by a curriculum by the curiosity of

7

8 CHAPTER 2. LEARNING ENVIRONMENTS

the learner and the paths he choose to follow during the entire process. Basi-
cally the learner absorbs the new concepts into the old concepts in a process
that Piaget calls assimilation, and constructs his knowledge in the course
of actively working with it. Obviously the learner can build false hypothe-
sis on which will build even more of them, but during this process he will
somehow encounter the fact that something isn’t right and will understand
that he has been wrong somewhere and thus, with the help of a teacher that
is more like a mentor or tutor that knows already everything that concerns
that particular ﬁeld of knowledge, he can truly learn with what is called the
trial and error process. Actually our educational system rejects the creation
of "false theories" made by the learner, thereby rejecting the way a person
really learn. All of this is also seen as a social activity in which learning is
mediated through the social interactions among the learners as they engage
in the learning activity, thus collaborating instead of competing.

Papert exploited this collaborative nature of learning and also the previous
stated theories, in the language Logo and the physical and virtual object
called “the Turtle”. With these two tools, he built a L.E. for learning math
concepts, and the students were engaged in the process of learning in a col-
laborative mode, sharing ideas and thoughts and reasoning about solutions
for given problems. He did not create a tool in which a student can put a
problem and then the computer solves it like a calculator will do. He went be-
yond the classical notion of computer as calculator, and thus avoiding putting
limitations of classical tools, like calculators and text books for example, in
the way we use new technologies like a computer. Papert understood that
computers got so much more potential than classical tools and he imagined
to use them as hosts of micro-worlds in which certain subsets of math rules
where true and implemented, in its particular case math rules. The student
was able to explore a simulated world without following a particular curricu-
lum, or list of concepts to learn in sequence. The student was free to explore
the micro-world and built a personal mental ﬁgure of what math represented
to him, while maintaining all the basic rules true to every interpretation of
all the student that were taking part in the process.

2.2. EXAMPLES OF LEARNING ENVIRONMENTS 9

He said, in the early 1980s, that most of what has been done up to now under
the name of "educational technology" or "computers in education" is still at
the stage of the linear mix of old instructional methods with new technolo-
gies, as a way to remark the enormous potential of the new technology. This
new way of thinking and usage of the tool called computation is still at a
stage very similar to what Papert had in its times. In fact in its recent book
Douglas Rushkoff [4], in the attempt of describing a set of rules that someone
in the digital era should live with, analyzes what kind of usage is made of
the computer nowadays. The result, after 30 years so far after the work of
Papert, is shocking: we are still using this new technology of computing as
it was the expected usage of a previous technology, for example the printed
paper. We are mainly treating the computer as an evolved writing machine,
an evolved book, metaphor of Gutenberg era. In the context of L.E., learn-
ing in fact still goes mainly for books, reading and writing processes instead
of interactive environments that engage and require active participation of
students. Both Papert and Rushkoff in their books wanted to incite the use
of computer for higher purposes: student should be able to use it for what
technologies it brings to the world of today, mainly its programmable capa-
bility. But this one is a specific topic which we will cover later.

But as the matter of fact, we are still far from what Papert imagined, maybe
it’s due to the Conservatism in the world of education. Returning to the
concept of L.E., example of these environments, or micro-worlds, are briefly
described in next session, where we can really take the essence of the concept
of experimenting and understanding and learning at the same time without
a prefixed curriculum of learning in which you have either "got it" or "got it
wrong", no learning-by-mistakes allowed.

2.2 Examples of Learning Environments
To better understand what this abstract concept of L.E. is, we now briefly
analyze what is offered in the education "market" and its characteristics.


We can differentiate between L.E. with or without the computer aid. L.E.
without computer aid are classical environments born with the school en-
vironment itself, where learning is achieved with lessons, presence of a cur-
riculum, a grading system, books, written exams and so on. Computer are
used only as mere tool of calculation. Some schools, by the way, constitute
a different and more interesting L.E.: Montessori schooling system and edu-
cation is a kind of approach toward learning developed by italian physician
and educator Maria Montessori in which education is characterized by an
emphasis on independence, freedom within limits, and respect for a child’s
natural psychological and cognitive development.
It follows a constructivist or "discovery" model, where students learn con-
cepts from working with materials, rather than by following a particular
curriculum, with the help of a teacher that helps them understand doubts
and concepts.
L.E. with the aid of computer we can say that generally take some of those
principle of a Montessori-like learning system, and like Papert with Logo
and Turtle graphics, they create a set of micro-worlds, and environments, in
which the student can explore and understand in its own ways the set of rules
implemented in such environments, rather than following a prefixed point of
view. In this computer aided environments various fields are targeted and
many of them involve a multi-field scenario. L.E. with computer aid con-
stitute a coadjutant to the classical environment of school but are also used
in certain situation where there is no schooling system, like auto-didactical
learning, or e-learning. What follows is a list of examples of the most pop-
ular computer aided L.E. For purpose of argumentation, we divide them in
directly related to or not directly related to our field of interest in this work
which is learning programming.

2.2.1 Not directly related to learning programming
Starting from L.E. that aren’t directly related to our field of interest which,
again, is learning programming, is worth talking about some of the most
famous examples of environments. In the field of math we have the prime


example of the above cited Papert: Logo language and Turtle Graphics. In
his book [1] he says that:

Our education culture gives mathematics learners scarce re-
sources for making sense of what they are learning. As a result
our children are forced to follow the very worst model for learning
mathematics.

And with this and similar motivations he built the Logo environment, aimed
at providing a way for young learners to actually learn math through a
metaphor they could relate with: the Turtle and the micro-world were it
lives. The environment gives the student the ability to find, explore, play
and getting used to concepts of math and geometry in an Euclidean space
through the use of a on-screen turtle or a physical turtle robot, both of them
controlled via code that the student types on a computer. As a side effect
the student learns to code, but primarily he get notions of angles, distances,
abstract concepts like circles, and so on, and composing code through mod-
ularity, he then engage himself and other children to draw various figures.
The turtle moves with commands that are relative to its own position, and
when it moves leaves a trace if the ’pen’ is ’down’. For example there are
command to make the turtle go ’forward’ ( or ’fd’ for the abbreviated version
of the command ) of a certain amount of space, or ’back’ of another amount
of space, make it ’turn right’ or ’left’ ( ’rt’ or ’lt’ for the abbreviated version
of the command ) by a certain quantity that in fact is directly mapped to
angles, degrees, and so on. Due to facilities of the language, is possible to
iterate, abstract, modularize the code, letting the student think in its own
way, free to explore, learn and solve the problem in its own personal way. A
student could understand the turtle’s motion by imagining what they would
do if they were the turtle, making this metaphor able to let the student feel
the problem to solve on its own body, like if he were identified in the turtle
object. “How do you draw a circle?” the teacher may ask, and the student
pretending he is the turtle could say “I move a little bit forward, then turning
a little bit to the left, and then again moving and turning a little and so on”
and in the meantime he starts to think about the quantities and find for him-


self that exists such things called angles and for example that the total sum
of this angles for a circle is equal to 360, and so on. All without introducing
him to theorems or whatever, letting him free to discover. What follows is a
snippet of Logo code that creates two procedures, procedures expressed more
like a verb in the form of “to do-something eventually-with-parameters”, one
procedure that creates a circle and the other one that creates an abstract
drawing made of circles, and this one is called.

to circle

repeat 45[
fd 8
rt 8
]

end
to logo

repeat 20 [
circle
rt 18
]

end
logo

Drawing process of previous code.


The process is somewhat interactive, and thus the student can see the changes
on the behavior of the turtle ( on-screen or physical robot ) when he inputs
new code. This is a completely new approach compared to reading a math
book and try to figure out what happens, and memorizing, without really
understanding why, theorem and rules. The role of the teacher in this en-
vironment is that of a participant in the learning process of its students,
helping with hints or aimed questions to give an input to students that ap-
pear stuck, helping them reach the goal. Logo itself is no longer maintained,
but a vast amount of clones are still in the “market” at the moment, each one
with its exclusive feature, like for example the possibility of having multiple
turtles that concur and communicate to each other via so called ’messages’.
A basic version of Logo is also implemented in the Python Language 1 .
Following the path of drawing and animating, the next L.E. that we are go-
ing to describe is directly influenced by the Logo environment, but abstracts
from the need of typing code and thus is much more easy to get used to it,
introducing a metaphor of block-programming. This L.E. is called Scratch2
and it was developed by the Lifelong Kindergarten group at the MIT Media
Lab. The metaphor it introduces consists in letting the user build programs
and scripts by putting together blocks one upon the other, stacking them,
nesting them in various ways for the final result of a sequential list of blocks
that achieve certain goals.

There are various kinds of blocks, data block, control-flow blocks, drawing
blocks and many more. By dragging them from the palette onto the can-
vas and combining them like Lego blocks, the user commands a little cat,
which is the same concept of the Logo Turtle introduced by Papert in Logo
environment. Uses are various, varying from math learning to storytelling
and animation and even game creation, with the help of some functionali-
ties that make the script of the user sensitive to input and thus interactive.
1
Turtle graphics is a popular way for introducing programming to kids. It was part of
the original Logo programming language developed by Wally Feurzig and Seymour Papert
in 1966. http://docs.python.org/2/library/turtle.html
2
Scratch: a programming language for everyone. Create interactive stories, games,
music and art - and share them online. http://scratch.mit.edu


Scratch has also been used to teach in various introductory courses in CS for
non-CS-major students, because it helps grasping fundamental programming
concepts without being too formal or showing too many irrelevant ( for the
beginner ) details. A dedicated Online Community let Scratch user share
their programs and learn from what other users have produced with Scratch.

What follows is a screenshot of the application, in which the same program
listed above in Logo language is expressed but with the new metaphor of
blocks.

Code and drawing process are in the same window.

The image shows a snapshot of the little cat, mascot of Scratch, moving on
the canvas and drawing the same picture of previous example.

We can see clearly that the code is somewhat absent, but in reality is ex-
pressed by those stacked blocks, which respectively clean the canvas, put the
pen down on the canvas, start a ﬁrst loop of 20 iterations of a second loop
that draws a circle and a command that rotates the cat by certain amount
of degrees clockwise.


Another environment that uses this block metaphor ( before Scratch was
invented ) is ALICE [10, 11] that also aims where the previous cited Logo
and Scratch point, but it does so by using a 3D world instead of a 2D plane,
putting its emphasis on visualization of concepts and storytelling.

There are many others L.E. similar to the ones depicted above that we can
talk about but main features are at the moment the one that are in those
environments.

For more advanced math environments it is worth naming Geogebra 3 which
has a fully implemented 2D and 3D environment, letting the user explore all
of the major concepts like mathematical functions, points, vectors, segments,
lines, polygons, conic sections, inequalities, implicit polynomials geometry,
general algebra and calculus all in an interactive way, meaning that all of
them can be changed dynamically and changes propagate and update the
environment in which those objects live. The main difference of a program
that simply calculates results of expressions, or derivatives o integrals and
so on, is the interactivity tied to the visualization of the concept that are
handled by the student. Teachers and students can set up the learning by
exploring technique to make conjectures, hypothesis and find out about ge-
ometric theorems simply by playing with this micro-world where math rule
are implemented. What follows is a picture of the environment while creating
an interactive notepad for understanding how two important math functions
like sine and cosine relate to one another in respect to a shift value that is
interactively modifiable.

3
Geogebra: a geometry package providing for both graphical and algebraic input.
http://www.geogebra.org


In this really simple and silly example Geogebra is used to interactively find
out, by moving the slider, the proof of why the two function depicted above
start at value 1 when fed 0 as argument in case of the cosine function and
start at value 0 when fed with 0 as argument in case of the sine function,
and by moving the slider until they overlap each other at a shift value for
the sine function that is in fact 1 ⇡. The toolbar offers so many option that
2
entire courses are based on the fundamental of this environment: a world
within a world. Geogebra is also integrated in another L.E. called Kojo4
implemented in the Scala Language5 , an new Object Oriented Functional
Programming Language that runs on the Java Virtual Machine. Kojo itself
is an environment with many different features that enable play, exploration,
creation, and learning in the areas of Computer Programming, Math and Sci-
ence, Systematic and Computational Thinking, Art, Music and much more.
It aims to be an all in one environment.

Moving on through the list of non-programming L.E., we must talk about
those environments that simulate the real world through physics engines with
huge sets of real world physics rule implemented: from gravity, to springs, im-
4
Kojo Learning Environment: http://www.kogics.net/sf:kojo
5
Scala: http://www.scala-lang.org/


plementing forces, temperatures, friction, laws of particles and waves, light,
sound and so on. The one choose as a representative is called Algodoo 6 ,
previously named Phun and open-source, that has gone commercial due to
its popularity. Basically is a 2D-simulation software designed in a playful,
cartoony manner, built for creating interactive scenes and, like Papert would
like, encourages students and children’s own creativity, ability and motivation
to construct knowledge while having fun (that why its previous name was
Phun ), because it is both entertaining and educational. Students can create
simulation scenes using simple drawing tools like boxes, circles, polygons,
gears, brushes, planes, ropes and chains and interact with those objects by
click and drag and drop, make changes by rotating, scaling, moving, cutting
or cloning the objects. Is also possible to add more physics in your simula-
tion like ﬂuids, springs, hinges, motors, light rays, tracers, optics and lenses
or playing around with diﬀerent parameters like gravity, friction, restitution,
refraction, attraction, and so on. Again, the students learns by playing and
then he better understands certain theorems and rules of physics. Follows, in
this case too, a picture of a scene in which many components are simulated
at the same time, that interact and change the world around them.

6
Algodoo: http://www.algodoo.com/


There would be a lot more of environments worth describing for their par-
ticular field like the complete software solution targeting children in poor
areas of the One Laptop Per Child7 laptop, mounted with Sugar OS8 , an
operative system studied to integrate various L.E. all in one device. The
main characteristics of a generic L.E. are by the way already depicted by
these few examples that we just analyzed. From now on we focus our aim
exclusively to environment dedicated to learning programming, which is our
field of interest for this work.

2.2.2 Directly related to learning programming
In this section we are going to briefly analyze what is available at the moment
in the “market” of L.E. targeting our field of interest, for this work of the-
sis, that is learning programming. It’s worth remembering that educational
programming learning environments are designed primarily as a learning in-
strument and not so much as a tool for writing programs for real-world work.
With this viewpoint in mind we first discuss rapidly the characteristics of his-
torical tools for this purpose and then we analyze more recent, evolved and
specialized environments available today.

Starting from low-level oriented environments, which means environments
that make use of what comes right after machine code, namely assembly
languages, we find various implementations and dialects for concrete and ab-
stract machines. Being usually untyped and rigid, this kind of languages
and environments are used in combination of teaching the specific proces-
sor architecture they are written for, hence this is usually used in advanced
courses for learning about fundamental computer processor operation. Little
man computer ( LMC ) is an educational model of a computer used to teach
students all the basic features of a modern computer because it models a
simple von Neumann architecture, programmable in machine code ( usually
in decimal ) or in assembly code, which then is converted and compiled into
7
One Laptop per Child: http://laptop.org/
8
Sugar OS, Sugar Labs—learning software for children: http://www.sugarlabs.org/


machine code. Assembly code usually it is used for abstraction and read-
ability purposes of machine code. This model is based on the metaphor of
a little man that lives inside a computer in which there are 100 mailboxes
numbered from 0 to 99, which represent the memory, and there are two mail-
boxes, one for inbox and the other one for outbox, used for receiving and
giving data. The center of the computer, is a working area in which there
is a box called the accumulator that executes two function, addition and
subtraction, and then there is also another box which represent the program
counter that holds the next instruction that the little man has to carry out of
the memory. Instruction and data are in the same memory as specified by the
von Neumann architecture. The execution process is like follows: the little
man has to fetch the instruction at the mailbox numbered like the program
counter, then he increments the program counter and decode the instruction
and retrieving the data from the mailboxes on which the accumulator has to
work on and then after the execution of the addition or subtraction the data
will be stored inside the mailbox from which the old data was retrieved. The
little man executes then the next instruction or halts.

This metaphor, besides its low-level concepts, helps the student to identify
into the little man itself and understand the data-flow and operations that
are executed in such low-level details and helps him to program in such low-
level terms. Obviously it is a simplified version of a calculator, working with
only two function and on reduced subset of numbers, but it is quite as pow-
erful, computationally speaking, as a Turing Machine.

More concrete models are subset of the MIPS architecture, restricted for ex-
ample to integers, but they follow the same concept depicted so far, even if
there is no little man inside the processor architecture, but busses that pass
data from ALU to memory and viceversa.

One can also build its own language and environment, low-lever or not, made
of tools for simulating a computer machine and its internal memory, all upon
other existing language as Domain Specific Languages (DSLs). It is the case


of the AREtool, a customizable tool built in OCaml for the Computer Sci-
ence course of Computer Architectures here in Cagliari. This tools receives
a program in a speciﬁc assembly code, that is then interpreted and executed
and let the user say how many steps of computation he wants the tool to
execute and lets him analyze the state of the memory at each steps, letting
the student able to understand the operations on data and so on.

Moving on toward high-level oriented environments, that aren’t meant to
be associated with high-level languages used by professionals everyday and
haven’t got features for promote learning programming, we focus on those
particular tools that provide instead, like all the previous L.E. depicted so
far, a sandbox for playing, grasping and understanding the fundamental con-
cepts of programming in this particular case. We can make an exception
for the BASIC and Pascal languages, that were the primary choice in intro-
ductory computer science classes for teaching students programming, which
haven’t got an environment but they were created with the intent of mak-
ing programming learning easy also for non programmers. The aid given to
the learner here is in the simplicity of the language itself that lets beginners
express their ideas and letting them create interactive programs with the
help of clear syntax and clear error messages, without the need of knowing
operating systems and computer hardware details. Many dialects and appli-
cations were made, but one in particular is worth mentioning: Basic-256. It
is an easy to use version of BASIC designed to teach anybody the basics of
computer programming and it uses traditional BASIC control structures (
for loops, goto ) for ease of understanding program ﬂow-control. It has the
code editor, text output window and graphics editor window are all visible
in the same screen, letting the learner focused in one environment, without
confusing him through various windows and steps to go through. Like tra-
dition, we will see that this environment implement when possible a built-in
graphics mode that allow to draw pictures on screen after minutes, like the
Logo Turtle. Picture of the environment calculating a fractal.


Moving on, we can now also consider under a different light the previous
discussed Logo, Scratch, Kojo and Alice that were designed for building rea-
soning skills but also, as a side effects, teach how to program. With the Java
language at his base, we can consider talking a little bit about BlueJ 9 and
Greenfoot 10 , developed by the same team but with different approaches to
learning java programming. The first one is considerable as an evolved text-
editor & compiler couple, but a reduced professional IDE and does provide
rapid interaction with the created code, letting the user create object, explore
and inspect them, making them talk to one another, understanding in this
way the fundamentals of Object Oriented programming by providing con-
crete experiences for abstract concepts. One can code and execute standard
java code. The main focus and goal of this approach is for beginners to more
easily develop a consistent mental model of object-oriented systems, their
properties, and their execution. Main interface visualizes code and classes
9
BlueJ: http://bluej.org/
10
Greenfoot: http://www.greenfoot.org/door


like a UML diagram keeping the environment and the interaction simple and
concise. There is no need to say that the pedagogical approach represented in
BlueJ is still based on constructivism and visualization. Greenfoot, instead,
teaches object orientation with concept of ’actors’ that can be programmed
to act independently which live in ’worlds’ (represented by a rectangular
screen area) and use them to build games, simulations, and other graphical
programs, by programming those actors with code for movement, rotation,
changes of appearance, collision detection and much more.

Almost the same basic elements of Basic-256 interface and interaction are
in KidsRuby11 . It presents an editor where the learner can type in its code
and a view for analyzing the output of execution, it can be text or visual,
in the last case the same classical visual output of a Turtle that draws like
know we expect to do, but does not show the state of the memory, variables,
data. It comes in forms of application executable or with its own live system,
KidsRuby OS. This type of learning system interface is being adopted also
on interactive online courseware like Codecademy 12 , Khan Academy 13 and
many other more that in the recent times are contributing to help self-learners
increase of knowledge in the ﬁeld of computer programming.

Here is an example of interface of this kind of environments: to the left side
we have and interactive editor and to the right side its output executed or in
execution.

11
KidsRuby: http://kidsruby.com/
12
Codecademy: Learn to code http://www.codecademy.com
13
Khan Academy: https://www.khanacademy.org/


A particular set of high-level environments for learning programming con-
cepts are programming oriented games. They are interactive and responsive
for their underlying nature of games and provide a micro-world to explore,
in which create and learning, but at the same time they force the learner to
think in terms of abstract programs and rules.
Microsoft’s Kodu 14 is a visual programming language made speciﬁcally for
creating games, simple and entirely icon-based. There is no code to type.
It is designed to be accessible for children and enjoyable for anyone. The
environment runs on the PC but also on the Xbox, allowing rapid design
iteration using only a game controller for input. Programs are composed of
pages, which are divided into rules, which are further divided into conditions
and actions. Conditions are evaluated simultaneously. Provides specialized
primitives derived from gaming scenarios. Programs are expressed in physical
terms, using concepts like vision, hearing, and time to control character be-
havior. Kodu can express advanced game design concepts in a simple, direct,
and intuitive manner. The world itself is a 3D world that can be changed by
the user or by the actors programmed accordingly to do a terraforming-like
operation.
Here we show the process of programming an actor (WHEN condition DO
action rules) and the surrounding world on the background.
14
Kodu Game Lab: http://research.microsoft.com/en-us/projects/kodu/


The last example that we are going to show is a far more formal game than
the previous one. It is Manufactoria 15 , a simulator and robot-based game for
learning automata theory. The main goal here is to build a set of orchestrated
robots that work accordingly for accepting or rejecting input strings (inputs
that have to go from top right to the bottom of the 2D game board where
particular holes are located) that have to be processed and respect level spec-
ifications. It may look easy at first levels but rapidly becomes difficult and
the learner may feel the need to use pen and paper to draw and reason about
automatons (if he studied them before, otherwise will learn them playing the
game) that can solve the problem. Strings can be read from or written on
a tape, like an advanced turing machine, and many more controls appear
when you progress into the game. The interface is pretty straight-forward
and responsive.
Here is a quick look at some of the screens of the game, from level selection
to real gameplay and test of the automaton with input tape.

15
Manufactoria: http://pleasingfungus.com/Manufactoria/


It is also possible, during the test of the automaton, to control the speed of
execution of the process.

As always there will be a lot more environments worth of discuss, but here
we have depicted the common features present in almost all of the modern
L.E. for learning programming.

Chapter 3

Learning Programming

In this chapter we are going to discuss what an ideal L.E. may look like,
what features it must have and then analyze where the state of the art fails
at doing so.

3.1 Learnable Programming
In the previous chapter we’ve talked about general concepts of learning envi-
ronments, involved directly or not to learning programming. They substan-
tially built up on the concepts that Papert took from Piaget and Montessori,
about constructivism, that he in his turn adapted to computer and computer
science, naming it “constructivism”. Thanks to an essay from Bret Victor,
called “Learnable Programming”[2], we are going to ﬁnd some key elements
and aspect that must be kept in mind for our work, that is building such
and environment for helping novice computer science students manipulate
and enrich their knowledge of programs and programming. Upon this rea-
soning and the previous depicted characteristics of existing L.E., we move on
critiques and propose a solution that will be explained in the next chapter.
Like said before, commonly used tools by students to learn computer pro-
gramming are systems that have been designed for purposes other than learn-
ability, exception made for those student that have luck and use those L.E.
discussed above, even if they do not completely represent what Papert though

27

28 CHAPTER 3. LEARNING PROGRAMMING

to be a reasonable environment for learning. We then need to build new ones
that have a different emphasis, almost like Papert did at his time, on learn-
ability.
Bret Victor at the beginning of his essay asks an important and tricky ques-
tion to the reader:

How do we get people to understand programming?

The question can be interpreted as asking what a person has to learn in order
to be able to program and/or what has to be done in order to make people
learn the right concepts about programming. He approaches programming
as a way of thinking, not a rote skill. He claims that learning programming is
aimed at building a robust mental model of an abstract machine with the goal
of solving everyday problems by being able to formulate an abstract program,
a set of instruction or steps to execute that bring the “programmer” to the
solution of the problem. He criticizes the fact that learning the features of a
particular language doesn’t help to solve the problem: there is first the need
to build and educate a problem solver and then in a second time the educated
learner can choose for himself what are the languages or technologies, that
can better implement abstract models built by the solver, use for the concrete
implementation of the abstract solution. At this moment of writing we can
say that the learner is doing the effort of adapt himself to the languages and
the technologies available and not viceversa, that is instead a better way to
use computer technologies and is a better approach to tackle problems, also
like Papert was hoping in its book. Computing education research is about
understanding how people develop robust models of abstract machines, and
how we can help them achieve those mental models.

Learning about "for" loops is not learning to program, any
more than learning about pencils is learning to draw.

It is then necessary to put the emphasis in the right things when creating
the learning environments. In general, people understand what they can
“see”, with the verb “to see” holding various meaning, varying from the phys-
ical ability to perceive light and colors but mostly the ability to understand

3.1. LEARNABLE PROGRAMMING 29

things, seeing their inner mechanisms and how are they working. In our case
if a programmer cannot “see” what a program is doing, he can’t understand
it. He has to try to figure it out by mentally following the flow of execu-
tion and this could be simple for small programs but starts to be difficult as
code complexity grows. Thus, the goals of a programming system should be:
to support and encourage powerful ways of thinking to enable programmers
to “see” and understand the execution of their programs. Most of the en-
vironments, besides their appearance of interactivity and understandability,
usually let “see” very few useful things and make understanding a difficult
process, mining the basis of good learning. And an interactivity feature, as
a standalone feature, is worthless for learning. This reasoning is in contrast
with the classical statement that says

"To understand a program, you must become both the ma-
chine and the program."

This is not the same as the machine that mimics the human, like the turtle
that helps reasoning like a living thing and not a machine, or the little man
that acts like a secretary and not a machine; in this statement instead is
the human that has to mimic the machine. This view is a mistake, the
program is usually “one sized” and forcing the learners to fit inside of it,
is wrong and inconvenient. It is this widespread and virulent mistake that
keeps programming a difficult and obscure art. A person is not a machine,
and should not be forced to think like one.
How do we then get people to understand programming? Paraphrasing what
said before with a proverb, “if the programmer does not go to the program,
then the program must come to the programmer”. And we do so by simply
changing programming and the way we learn it. We turn it into something
that’s understandable by people. We now, more than ever before, have the
tools that let us build systems that can go far beyond the reduction of our
multi-dimensional reality to a subset of dimension that fits the computer
but loses various important dimensions. For example it could be possible to
build such a system that goes beyond the simply act of manually coding the
machine, and upon that dimension create layers that interact with the user


via more and more complicated artificial intelligence algorithms that can for
example do the coding for us listening from our direct voice the specifications
of the application we want. But lets stay in the present for now.

Let’s start to find the major components of a programming system that well
supports learning programming. We can say that a programming system
has mainly two parts: the programming "environment" is the part that’s
installed on the computer, the programming "language" is instead the part
that’s installed in the programmer’s head. Each one of this two parts has to
give certain features in order to create a useful system. For the environment
we have that is required from it, at least, to let the learner understand the
meaning of the elements and words that the programming environment uses,
to let him follow the flow of things in order to understand what is happening
at each point, to let him also see the state of the computer in such ways that
explain who and why the computer act in certain ways. It would be also
nice that this environment promotes the creation from scratch and the build
more complex things upon them, and also it should be possible to create
a concrete thing and being able to generalize it with ease. The concept of
a system split between the computer and the head was derived from Will
Wright’s thoughts on games (Will Wright is the creator of some of the most
famous computer games like The Sims , SimCity, Spore ).
The other component of such system, the language, should provide a way to
relate the computer’s world to world owned by the learner, like the Turtle
metaphor does with the kid. The language should encourage to break down
thoughts into mind sized pieces, meaning that the learner shouldn’t have the
need of keeping in mind complex structures when building them because the
mind does not scale well for bigger problems and we need to focus on pieces
of knowledge that well adapts to our brain. But also with this feature we
should be able not only to go into detail of thing but also to abstract to see
the big picture of thing, by letting the learner able to understand and glue
previous built mind sized pieces together. These are some of the features
that it is nice to have in such systems but features are not the main point of
them because a well designed system is not simply a bag of features but is


a thing designed to encourage particular ways of thinking, with all features
carefully and cohesively designed around that purpose. The whole is more
than the sum of its parts. It is important not to implement them all but
carefully choice the right set of this design principles that they represent,
and understand how these principles enable the programmer to think.
In our field of interest, a programming environment is a user interface for
understanding a program and especially in one for learning, it must be de-
signed to explain. As the matter of facts, today even some of those L.E. that
we saw earlier do not explain very much. The whole process for now is like
a cooking show, ruthlessly abbreviated. First, you’re shown a counter full of
ingredients. Then, you see a delicious soufflé. Then, the show’s over. The
question rises: if such a show has sense to exists, would you still understand
how that soufflé was made? Would you feel prepared to create one yourself?
Not really. We need to “see” the steps that bring those ingredients to the
final form, passing through the various phases and procedures, otherwise we
are not able to judge for example if the procedure that create that result
was indeed correct. the same concept applies in programming but mostly
important in learning programming. Old tools or tools used by professional
are not suited for learning and even those environments who try to create an
alternative specialized for learning purposes, fails in some ways that we later
discuss. The programming environment and process exhibits the same ruth-
less abbreviation as this hypothetical cooking show. We may have the code
on the left and the result on the right, but are the steps in between which
matter most in learning phases. The computer usually traces a path through
the code, looping around loops and calling into functions, updating variables
and incrementally building up the output. We generally still “see” none of
this big amount of information, again useful for the learner. Programmers
are expected to write code that manipulates variables, sometimes without
ever seeing the values of those variables. Also when non creating but read-
ing code that someone else has written or created, readers are expected to
understand code that manipulates variables, without ever seeing the values
of the variables, without seeing the data flowing through procedures and so
on. As Bret Victor remembers to the reader, the entire purpose of code is


to manipulate data, and we never see the data. We only see when we input
the data and when we retrieve the results. Usually no information about
the inner manipulation of that data or the decision upon it. We write and
read code usually by pretending to manipulate data ourselves like if we were
computers. And this has to be turn in the opposite way, we have to make
the computer, and the environments for learning or not, show us the data.

If you are serious about creating a programming environ-
ment for learning, the number one thing you can do more im-
portant than live coding or adjustable constants, more important
than narrated lessons or discussion forums, more important than
badges or points or ultra points or anything else is to show the
data.

With this quote, we now have already an important concept explained clearly:
the most important thing to do is to show what is happening, which is better
than many cool features or the best prepared lessons (which also helps but in
this reframed context are less valuable than a mechanism to show the data
and let the learner easily understand and make his own idea about it). Since
the value of a variable varies over time, showing the data is intimately con-
nected with showing time. Hence certain L.E. do provide a set of controls for
manipulating the time, but still do not show the data, but limit this feature
for showing the ﬁnal result building step after step, which is by the way a
good thing to do but must be completed with some other informations. Here
is an example that Bret Victor shows in his essay regarding showing infor-
mation about what code is meaning and doing, showing variables and also
output as time passes and execution goes through its steps. This particular
code is building a graphic output by creating triangles and stacking them
following a procedure that rotates and scales them accordingly to obtain the
desired output.


Those environments can also be useful if they were like a canvas or sketch-
book, and serving like if they were an aid to the thinking process, like an
artist that can grow an idea from birth to maturity by continuously react-
ing to what’s in front of him. Programmers, by contrast, have traditionally
worked in their heads or in the best case they plan with pen and paper, first
imagining the details of a program, then laboriously coding them. But this,
as stated above for the need of visualizing the data, inner workings and vari-
ables, also in this case working in the head doesn’t scale, and seeing the big
picture all at once may be really difficult for professionals, and obviously be-
ginners will have much more troubles than professionals. This may be fault of
evolution, because the head is a hardware platform that hasn’t been updated
in millions of years, but it is also true that this kind of technologies have made
their appearance in the really last 50 years, that is nothing compared to the
whole time humans live on earth. Hence it does not make sense to continue
with this unproductive ways of learning, teaching and working, and it is time
to built ourself a better tool with the help of the older tools we have. So
to enable the programmer to achieve increasingly complex feats of creativ-
ity, the environment must get the programmer out of his head, by providing
an external imagination where the programmer can always be reacting to a
work in progress. Bret Victor points out that some programming systems
attempt to address this with a so called "live coding" environment, where
the output updates immediately as the code changes. Immediate update is
merely a prerequisite, a feature that not constitute a concept of interesting
environment by itself, but is the base for doing anything interesting. It en-
ables other features which require a tight feedback loop. In an environment
where you have to write the code and then save the file and then compile the
file and last executing the code, adding a feature like live coding wouldn’t


help much in terms of learning as like using an interactive REPL console (
Read Evaluate Print Loop ). Live coding, on its own, is almost worthless.
The programmer still must type at least a full line of code before seeing any
effect. This means that he must already understand what line of code he
needs to write. The programmer is still doing the creative work entirely in
his head, imagining the next addition to the program and then translating
it into code, while keeping the entire system in idle even if it is in a so called
“live coding” mode.

Another thing that may be useful introducing in a learning environment
would be a palette of available things that the environment can do at a
starting point, like if it were a toolbox or a box containing generic pieces
of Legos or bricks. With the analogy of the Legos, we can remember our
childhood while playing with them and we surely remember that as a first
act before starting to build, we often spread out all of the parts on the floor.
This provides more than simply quick access. It allows to scan the available
parts and get new ideas. When building a Lego car we might spot a wide flat
piece, and decide to give the car wings. This is a form of create by reacting.
In addition to reacting to the object under construction, the child is also
reacting to the parts he has available. The environment must be designed to
get something on the screen as soon as possible, so the programmer can start
reacting. This requires modeling the programmer’s thought process, and
designing a system that can pick up on the earliest possible seed of thought.
The environment must dump the parts bucket onto the floor, allowing the
programmer to continuously react to his raw material and spark new ideas.
For example we show how an interactive environment for creating simple
programs may look like, based on this last concept of showing the “parts”
with which someone can build something.


The picture above shows how the interaction is focused on creating by re-
acting, putting blocks, texts, colors on a toolbox from which we pick certain
blocks that we like and create. The data in this case is the code that is cre-
ated directly when drawing, with changing values when the manipulation is
in act. This in conjunction with an interactive visualization part, discussed
above, can constitute a good starting point for any environment, specially
for a learning one, that can lead the learner to focus on abstract concepts
rather than trying to fit everything in his mind in a way of reasoning that is
not naturally present in him.

Until now we’ve talked about the first component of a learning system, the
environment with the main characteristics that need to be implemented in
some way. The second part regards the language that is “installed” in the
programmer’s head and its design and we now talk about it and about it
is as crucial as the first component. In best cases they are co-designed and
inseparable. In this case the word “language” is not exclusively related to
the programming language but focus mostly on its abstract meaning. The
language here is a medium which convey information an permits communica-
tion between the programmer’s head and the environment. For the purpose
of understanding and explaining what a language may composed of, we now
present programming systems that were carefully and beautifully designed
around the way people think and learn. The main reference here is again the
enormous work of Seymour Papert called “Mindstorms”. In this book he has
done the work of depicting the principles that are necessary to understand
and build in order to design and create a learning system, while at the same


time introducing his own implementation, Logo and Turtle graphics. We
said that the Logo programmer draws picture by directing the "turtle", an
on-screen (but also physical) character which leaves a trail as it moves. The
the most important that the turtle does is that let the programmer identify
with it, because to figure out how to make the turtle perform an action, the
programmer can ask how he would perform that action himself, if he were
the turtle. This metaphor of identity is one of the characteristics that are
suggested to be present in a “language” for a given system. Actually every
programming language is made of metaphors, but some fit the mind better
than others. Standard imperative programming uses the metaphor of "as-
signing to variables", shuffling bits between little boxes. Unlike the Logo
turtle, this metaphor was not designed to resonate with how people learn
and understand; it simply evolved as a thin layer over the metaphors used
in the underlying machine architecture, such as "storing to memory". Alan
Kay[19], the creator of Smalltalk language and father of the laptop, points
out that

Assignment statements – even abstract ones – express very
low-level goals... Human programmers aren’t Turing machines –
and the less their programming systems require Turing machine
techniques, the better.

In his language, Smalltalk, he used a valid metaphor, the message. All
computation in Smalltalk is represented by objects sending and responding to
messages from other objects. In order to program the behavior of an object,
the programmer casts himself into the role of that object (to the extent of
referring to the object as "self"!) and thinks of himself as carrying on a
conversation with other objects. Which turn out to be a human capability
to conversing and role-playing. Not the bare metal of chips, or bit and
bytes of the machine, but something more abstract and familiar to us to
reason with. Another environment definitely worth of talking in matter of
metaphors and programming environments, very popular in the 80’s, was Bill
Atkinson’s HyperCard. All it was were a representation of a physical object, a
card, in a virtual environment. The card could be personalized with content,


numbered, and searched inside a deck of cards. One can move from one
card to another by clicking elements of the card and navigating through the
knowledge that one may create with this metaphor. Was used for various
applications, from interactive encyclopedias to huge databases. Obviously
this ideas and metaphors, lately added with network capabilities, constitute
the basis of the modern World Wide Web, as imagined by Vannevar Bush
in his “As we may think”. Processing1 language metaphor, since Processing
itself is an electronic sketchbook for developing ideas and promoting software
literacy within the visual arts, is is the "painter’s algorithm" metaphor. That
particular metaphor is not good for human because that algorithm is used
by the computer to fill pixels accordingly to the scene, and thinking in terms
of pixel coordinates brings to thinking about variables and where exactly a
shape should appear, without for example manipulating directly the shape
ignoring the underlying detail. For now it is a weak metaphor but as soon
they will implement a tangible and living environment, it would be a good
example and a good metaphor.
Besides metaphor features, another feature that we previously treated is de-
composition and modularity that lets tackle complexity in order to produce
understandable things in mind sized chunks. The Logo environment for ex-
ample let the user teach a new word to the turtle, that are in fact sub pro-
cedures that are made up by other procedures and commands. This feature
lies at the heart of functional programming languages like Haskell or Scheme,
OCaml, and so on. When writing a modular program to solve a problem,
one first divides the problem into subproblems, then solves the subproblems,
and finally combines the solutions. The ways in which one can divide up the
original problem depend directly on the ways in which one can glue solutions
together. Therefore, to increase one’s ability to modularize a problem con-
ceptually, one must provide new kinds of glue in the programming language.
Also recomposition is an important feature, directly following decomposition,
because once that a module is created, and it is fully working on its own with
no dependencies of any kind, it can be combined to serve other purposes with
1
Processing: an electronic sketchbook for developing ideas.
http://www.processing.org/


some other modules and create, in our case, a program that is a remix of
various other part of programs. Readability is also an important component
in language, meaning that the code should be clear and not cryptic. For
example in case of a function call, we usually have to get an hint of what
arguments are expected to be given in input. A function call in C like this

writeFile("hello", "greetings");

compared to a HyperTalk (programming language of HyperCard)

Write "hello" to file "greetings".

is far less understandable than the last one. Arguments are readable and
given in context and we surely say that “hello” is a string and “greetings” is a
ﬁle while reading HyperTalk code but we don’t know if the same is true for the
C counterpart. It is not just a matter of syntax, because programmers may
gain time and productivity letting the system “type” this code for them, which
indeed may be a nice feature to have, avoiding error while coding by hand.
Having the function name communicating meaning to the programmer is also
good sign of caring about the programmer. For example Cocoa language (
used in Mac Os programming environments ) has a function that even not
giving so much information about arguments, gives information about what
that function does and give as results, in fact this

arrayByAddingObject

is far more understandable than this JavaScript function

concat

that is a verb and not a “noun phrase”. Most Cocoa code can thus be read and
at least vaguely understood without documentation, because it is not am-
biguous or misleading like other competitor languages, that are also involved
in learning processes.
These design principles were presented in the context of systems for learning,
but they apply universally. An experienced programmer may not need to

3.2. WHERE STATE OF THE ART FAILS 39

know what an "if" statement means, but he does need to understand the
runtime behavior of his program, and he needs to understand it while he’s
programming. So it is necessary to rethink, as soon as possible, the whole
programming environments and languages to accommodate useful features
that can improve productivity of programmable systems.

3.2 Where state of the art fails
With this analysis made by the help of Bret Victor’s essay, that expresses
many key points collected by various figures in the field of computer pro-
gramming, we now try to apply those concepts and those principles to the
state of the art to spot where it fails implementing certain features that we
now understand to be necessary in a programming environment, specially in
a programming learning environment.
Let’s recap what features may implement such environment.
The whole environment should be a micro-world, a sandbox, a simulator with
a underlying set of rules that represents what is possible and what is per-
mitted in that micro-world, and thus actually depicting its limits, where the
learner can explore and learn by experimenting various actions. He mainly
learns by viewing the process of execution of its command and viewing them
operate on data and he should be able to control this visualization in some
way, for example by going through the steps of the program execution, back
and forth in “time”. It is also useful to give a metaphor to the whole system in
which the learner can identify himself in, like the turtle in the Logo language
or the message in the Smalltalk language, or even the card in HyperCard. It
should provide some kind of modularization capability, in order to decompose
difficult problems into small pieces, that may be combined in various situ-
ation to build something different from their official purpose. There should
also be a toolbox of pieces that let understand that is possible doing in the
micro-world. It is nice to have implemented a somewhat tight feedback loop
to let the environment being interactive and not a static process that has to
be repeated over time by the hand of the learner: if it is possible, this pro-
cess should be automated and made interactive and engaging. The learning


experience, lacking immediacy, is slow to change the student’s intuitions. If
we are going to show a language, which written or not we are certainly going
to, it should be clear and not cryptic, understandable even if we are only
reading a “code” created by others, and we must avoid introducing ambigu-
ities in the system. These principles are only some of the most important
in order to create a good learning environment, but where do the previous
environment that we analyzed fail? Let’s take for example the same subdi-
vision that we had previously, not directly related to programming L.E. and
directly related to programming L.E.. The ﬁrst example of the ﬁrst group
was the Logo language. In the matter of visualization, it fails in showing the
state of the turtle itself when we decide to hide the turtle! We have to keep in
mind while using the turtle its position and direction in which it is thanks to
the last command. We can say that is a minor fault due to due fact that we
hide the turtle, but it would be nice to give the information somewhere else
on the screen, maybe in the corner, a small area which informs us orientation
of the turtle and maybe its actual position with some kind of special colored
point. The other thing is that we have to manually code, an error prone
procedure that could lead to useless time consumption in case of search of
error in case of big programs (however if the program is well structured and
modularized, which is possible to do in Logo by creating new “words” for the
turtle). During the execution it would be nice to have some kind of reference
to the execution of the code, maybe by highlighting the current row that is
being executed. Some of this problems are solved in recent versions of clones
of the Logo language, like in Scratch, that was the second example that we
brought up. It avoid the user typing code, but with the great metaphor of
blocks, it ensures no syntax error, which for a learner it is a great thing to
ease the process of learning itself. Scratch also shows in a special zone of
the environment, the data about the position and orientation of the Turtle
(depicted by a new mascot, the cat), data that is shown as number but in
case of the direction of the mascot, is shown graphically by a little version
of the cat that is oriented in the same direction of the cat present in the
canvas(hidden or not). The language in both Logo and Scratch, written in
one and graphical in the other one) is clear and not ambiguous, but Scratch


improves a little bit Logo by showing the group of blocks that is being ac-
tually executed but doesn’t have a ﬁne grained resolution, because it does
not show the block involved in that particular moment of computation. By
the way is more interactive and engaging than Logo. Regarding Geogebra,
we have to say that the only thing it “fails” is that does not yet implement a
way to produce functions of a time variable, which can be faked by using a
manual slider tied to the value of a variable with which one can manipulate
the plots, but it is actually the best piece of software out there for learning
Math because it implements almost all possible principles depicted so far,
from the interaction to the toolbar and the language itself. Algodoo is also
good as Geogebra, but it lacks the feature of handling time too, it does not
show a way to control the physic simulation, one can only play the simula-
tion without analyzing step by step the state of it, the state and direction
of forces, interaction between elements: this brings the user to launch the
simulation various times instead of letting him able to see maybe a ghost
shadow upon the simulation that can maybe tell where the ball is going to
bounce in the future or were it has been in the past of the simulation. Still
it is a problem of poor visualization.
For the directly related to programming we had the Basic implementation
with Basic-256, which by itself it is a great piece of software targeting new
programmers. It shows almost everything that is valuable to showing while
learning programming, like state of the system, output, state of the vari-
ables, but even if does this awesome job, it would be better if it had the
option in the step-by-step execution, to go backward in the execution and
to highlight the code that is being executed for more clear comprehension of
algorithms. Same thing holds for the online courseware Khan Academy that
hides the step of execution and does not show what row of code is executed
which can be confusing if someone is reading someone else code. It does not
show the state of variables and this is somewhat disappointing for a pro-
gramming learning environment. The ARETool could be improved by a nice
user interface(actually absent) showing all the information at each step, and
not only after specifying how many steps to do and manually controlling the
state of the system. ﬁnally if we have to compare what actually is used in


introductory courses, like BlueJ, we have to move the same critiques of lack
of visualization during execution and lack of control over the computation.
By the way, at the moment of writing, most of the schools use, as teaching
tools, tools that are used by and though for actual professional, people that
already knows in the best cases what is going to do with code, and are tools
that did implement almost none of the principles depicted above. If one want
to understand what his program is doing, he has to use unconventional ways
to track the flow of execution with the help of print statements here and
there in the code, or actually using a complex and not so interactive debug-
ging system in a second time, not right from the beginning in the first place.
In learning to program, many students struggle with developing algorithms,
figuring out how to apply problem solving techniques in their programs, and
with how to use common programming constructs. Mostly because they do
not see what is happening and they cannot built their our idea and inter-
pretation of the world of programming. One can’t learn well by hiding the
content of what he is learning. But even professional rarely use this form of
understanding of what’s going on in their program. Experienced program-
mers almost exclusively use form of debuggers when they are needed. I would
say that not using a debugger is a sign of inexperience. Stepping through
code line by line is the best way to trace the flow of execution. Debuggers
nowadays are sadly only a feature and not the main concept of working, they
are put aside when instead they should be the main part of a programming
system together with the editor. Most existing debuggers are old-fashioned,
have careless interfaces, and require the programmer know and understand
concepts and paradigms that are difficult to master, and, nowadays, not fair
to expect most programmers to use or know. As a result, most modern,
experienced programmers, go to great lengths (they spend too much time)
to learn the skills necessary to write the kind of code that rarely ever has to
be debugged in a debugger, to avoid the pain of the experience. It could be
much more useful instead using this kind of tools during learning, in order to
be able to write in, the future, code that is almost right from the beginning,
thanks to deep understanding of things. And even if the code isn’t correct at
the first shot, what better way to track down a bug than to actually follow


the execution of the code? This kind of system is surely more powerful than
prepackaged and static animations of the inner working of an algorithms,
since the system is interactive, it promotes changing values and codes and
let the novice students see “what happens if..?”, actually letting them answer
their own doubts, instead of letting them wondering in front of a black box
that does not let transpires useful information. In the next chapter we will
see how to create an environment that suit our need and follows those princi-
ples of good design of a learning environment, that will also connect creation
and process of creation, namely coding and its workings.

Chapter 4

Inventing Eple

In this chapter we will create a concept of environment that targets novice
programmers, ideally in between the phase that involves the passage from pen
and paper flowchart description of basic programming and the phase of real
world programming, to better help the transition from one way of thinking to
the actual way of doing things in programming nowadays. Environment that
will be based upon those principle and design methodologies that we have
talked about so far. After proposing a theoretical concept we will discuss
on how to build that by finding pre-existing software solutions that better
fit our needs and how mix and improve them to achieve our goal, that is a
concept of a new tool that provides a possible approach to actively engage
students in increasing their knowledge and understanding of programs and
algorithms.

4.1 Finding a solution to the problem

We have said before that for creating a concept of a better L.E. for the
programming field, we must follow some basic principles mainly regarding
visualization of information and interactivity. Let’s first see what kind of
problem our target user faces nowadays in terms of environment.

45

46 CHAPTER 4. INVENTING EPLE

This image above shows what current environments essentially consist of, in a
“editor and compiler” form, even in advanced IDEs (Integrated Development
Environments). There is a phase in which you edit the code of your program,
then you save it and compile or interpret it to obtain the executable or
directly the evaluation in case of interpreters. Then you have to repeat the
process allover again in case of something has to be changed in the program
and hence in the code. For novices this is not a right kind of tool for learning,
it is a static process that may be repeated over time, but it is certainly not
interactive and even in REPL environments, they still do not convey and
visualize information about what’s happening “under the hood”, unless the
novice learns, while he is learning the basic fundaments of programming, also
how to use a debugger, resulting in a cognitive overload that may cause the
loss of important information regarding programming because he memorized
other, at that moment, useless information for that context. So the main
problem is that this classical ways of learning through the use of these tools
did not easily help the learner in the act of understanding what is going
during the execution of the program that he previously wrote. He’s like
trying to learn how to ﬁre a gun and centering the target at the same time
while keeping his eyes closed. It is very hard for novice to take the right aim

4.1. FINDING A SOLUTION TO THE PROBLEM 47

when temporally blind. So does the programmer in its first stages, when is
trying to figure out how to apply in a useful way concepts of problem solving
learned from teacher and books.
In the next pages we are going to propose a solution for this problem, and
build a concept environment that is more suitable than this old style learning.
Since the user is producing programs, the main thing to visualize here is then
the program created itself and its execution involving the state of variables,
functions, and the stack of function calls. These things, like stated previously,
are not visualized in a classical development environment if not manually
specified by activating some kind of debugger. Then we are also going to
care care not only of the environment and its interface but also we will take
care of the other component of a L.E. that is an adequate language.

4.1.1 Conceptual prototyping
To visualize the execution of a program we are going to structure the whole
environment as a simulated micro-world, where the world itself is a computer
with its constrains and its capabilities to compute algorithms and so on. To
be able to have this kind of simulation, we must have a mandatory form of
code editor and a kind of visualizer of the execution. These are the main
components that we need for such a system. It should be structured in a way
that the learner doesn’t have the need to leave the environment for other
purposes that quitting the learning session, in other words the environment
should be made in such a way that provides everything needed for the learning
act.
There are mainly two ways of creating code nowadays: the first one is the
classical one, represented by the manual typing of the textual specification
of the code itself, which by the way is quite error prone specially in learning
phases, and the other one is represented by the so called visual programming
languages (VPLs), programming language that lets users create programs by
manipulating program elements graphically rather than by specifying them
textually. In between these two ways there are various shades, based on the
level of presence of the main characteristic of the editor. The one that we


think is best to fill the gap between an environment made of flowchart blocks
and an environment made of only text is the so called visually transformed
language. A visually transformed language (VTL) is a non-visual language
with a superimposed visual representation. that means that is in the middle
between the two named main ways to create code and programs. One kind
of VTL is represented by the blocks metaphor adopted by Scratch and many
other programming environments. It lets the user play with block and exper-
imenting while learning and while avoiding all those errors related to syntax
and abstracts from a specific programming language, like flowchart diagrams
do, while keeping a language (mostly english words and common program-
ming keywords) that easily relate to actual programming languages like C,
Python, Java, and so on. It hides programming constructs within the imple-
mentation of block pieces and focuses on the combination of functionalities.
Choosing a purely visual programing language with specific blocks would
mean to restructure the whole learning process of programming, pointing it
toward another specific way of programming called data-flow programming,
that is also a very valid way of thinking about computing but it is still con-
strained to certain fields of applications. We have decided to simply improve
the actual learning programming process by focusing on the creation on a
environment that shows what is needed to be shown instead of “reinventing
programming”.
So enough said about the conceptual kind of editor that we will adopt, the
block one, we now discuss of what a visualizer might have to be a good visu-
alizer of programs, since visualization is the main goal, output, that we want
to have from our environment. Since a program is executed line by line by a
generic computer that executes instructions, we have to decide what we want
to see. The most adequate resolution of interest here is the single instruction.
Going in detail would be counterproductive as going less detailed from that
and seeing a block in execution instead of the single instructions, like Scratch
does and we already said that is failing in that way. So considering this as
our resolution, the visualization should provide a way to go back and forth
in time during the execution process. A step by step visualization that let
the user understand inner workings without having to repeat from the begin-

4.1. FINDING A SOLUTION TO THE PROBLEM 49

ning the visualization like most one way algorithm visualization presentation
programs. It should visualize the state of the system at each step, like it is
possible to do in Basic-256 and in the ARETool. This involves mostly show-
ing the values of used variables and the stack of function calls in order to help
keeping track for example of multiple function calls and recursive function
calls. Since the editor chosen is a block editor like Scratch, and since we need
to fill the gap between the abstract way of programming with flowcharts and
real world code, we need also to show the code that is being produced by
the abstract block representation, in order to connect the learner with what
is going to do in the future, that is coding in a real world programming lan-
guage. This in combination with a step by step visualization of the state of
the simulation of the program created, with the help of a system that high-
lights the current row executed, constitutes the main components of a useful
visualization of programs. Obviously there would be some form of controls
in order to play the simulation, go a step forward or back, going to the end of
the visualization (end of the program) or to the beginning. A textual output
for showing the result of print statements would be also nice to have.
Now it is time to talk about the backbone of such a system. The connection
between the editor part and the visualizer part should be realized by some
form of backend that takes the block representation of the program created,
converts it in some kind of domain specific language (DSL) that would be
evaluated and as a result of this evaluation, it will generate an enriched code
that contains information that will control, through a dedicated part of the
environment, the visualization part of the system. Those information may
contain the real world code in its form of DSL that has to be shown to the
learner, a series steps of the execution of the program, namely a trace of
execution, with information about the state of the micro-world at each steps,
like variables and so on, and maybe the state of the output areas, like a
textual output area that shows what is requested with print statements. In
an environment like this, created with the purpose of letting “see” the inner
working of programs, these steps help making things more understandable.
All of this should be tied together in a tight feedback loop, in other words
changes made in the editor section of the environment would be propagated


to the backend in order to generate a new and update visualization when re-
quested. This would certainly improve the experimenting aspect of learning,
letting the learner answer his own doubts when building code, the various
“What if..?”s and would improve the speed of the process of trial and er-
ror learning, that is heavily slowed down in classical environments, like the
one currently used, where one has to save and compile and execute at each
time, manually. In this environment this aspect is automated, interactive
and reactive by design. All these components, the special editor that avoids
syntax errors, the visualization that shows the inner working, the backend
that generates the visualization and connects the editor and the visualizer,
all of this generate a visual program simulation (VPS) learning environment
that immerses students in the execution-time dynamics of execution of easily
created programs.
Here is a picture showing the abstract architecture of the environment that
we described so far.

To refer to this environment in the future in a short way, let’s give it a name:
EPLE. It stands for “apple” in norwegian and it is an acronym for EPLE
Programming Learning Environment.

4.2. FINDING PRE-EXISTING SOLUTIONS 51

4.2 Finding pre-existing solutions
If I have seen further it is by standing on the shoulders of
giants.

This quote from Isaac Newton remembers us that there is no need to reinvent
the wheel. In software development, every not so small project is rarely
started from scratch. So we are going to do the same, looking for pieces
from where to start our work and improve what’s actually available in the
“market” at the moment of writing.

4.2.1 Editor
The choice of the editor made in the conceptual prototyping phase was a block
programming editor, a type of editor that aids the learner avoiding him from
worrying about any specific language syntax or structure and thus reducing
to the minimum, zero in this case, the number of syntax errors that is possible
making with such an editor, and a metaphor surely easy to use and grasp.
The best solution found that implement this metaphor is a code editor called
Blockly1 . Blockly is a free and open source web-based graphical programming
editor, developed by Google aimed at application developers, where the user
can drag blocks together to visually describe logic that can then be turned
into working code, all without typing. The blocks look like jigsaw pieces,
are categorized and colored to provide intuitive cues to correctly connect
the outputs of each jigsaw piece. They snap together only if it is allowed
by type rules specified for each block by the language files that come with
Blockly. It is possible to create new blocks that may or may not receive or
give back data or that can or can not be stacked one upon another in order
to make or not block sequences, through access to implementation files. The
inner block representation may be converted into a specified language like
Python, Javascript, or other specific languages, thus converting a visually
created program into a textual program that present no syntax errors. Let’s
remember that novice programmers are fighting two battles at once: the
1
Blockly visual programming editor: https://code.google.com/p/blockly/


fight to translate their ideas into logical statements, and the fight to keep
the syntax legal. Blockly makes it completely impossible to make a syntax
error. There are no unbalanced parentheses, no unescaped strings, no missing
semicolons. Blockly allows novice programmers to concentrate on the logic.
This last feature is one of the most important features in EPLE, and simplifies
the learning process letting the learner free to focus on what matters. Blockly
is currently being use to program Arduinos, creating little web scripts, for
controlling a Lego Mindstorm robot, and many other use cases where the
user is expected to not have enough skills to code with bare hands or does
not have any idea of basic programming concepts. Its simplicity involves
exploration and learning the language and metaphor it holds, compared to
facing a blank screen with a blinking cursor waiting the user to type code, is
a matter of minutes.

4.2.2 Visualization
The choice of the visualization component was also made following what
said previously in order to have the basic elements of a useful visualization.
In the past few decades, many program visualization tools have been cre-
ated to assist instructors in this task[8, 12]. Sorva’s dissertation provides
a comprehensive overview of 40 such tools, which all look similar at first
glance: one GUI pane shows source code with the currently-executing line
highlighted, another pane shows a visual representation of run-time state
(e.g., stack frame contents, heap objects), and control widgets allow the user
to step forwards and backwards through execution points. Certain tools like
UUhistle[7], that gives a sort of environment like the one that we are going
to build but with an editor that does require manually coding and all the
problems that come with it, provides instead a useful visualization of the
execution of a program with the metaphor of frame of activation or stacks,
where information about variables and the general state of the machine is
given. By the way this solution is only available through a Java applet,
with all the software requirements that it needs. For keeping the whole en-
vironment coherent and in one place, we have chosen a recently developed

4.2. FINDING PRE-EXISTING SOLUTIONS 53

free and open source web-based software visualization tool for Python, which
is becoming a popular language for teaching introductory CS courses, that
works directly in the web browser (without installing any plugins), and it is
called Python Tutor[6], and it is built specifically for the purpose of learn-
ing programming by visualizing code execution. Unfortunately it does not
come in and interactive environment and comes without a proper editor. The
visualizer is being embedded in many online interactive books like interac-
tivepython.org, bringing interactivity to the learning process by letting the
student modify the code and have a freshly new visualization of the exe-
cution of his algorithms, without having to deal with old methods used by
instructors that typically illustrate program execution using graphical Pow-
erPoint lecture slides, which require a great deal of preparation effort, or by
drawing diagrams on a whiteboard, and is tedious and error-prone and read
only and not interactive. With Online Python Tutor (OPT) the students
are actively participants of the learning in a read/write manner, they can
step forwards and backwards through execution to view the run-time state
of data structures, and they can share their program visualizations on the
web.
The motivation of choosing OPT over the other available solutions, other
than the fact that that runs within a web browser without any required soft-
ware or plugin installation, are tied to the possibility of integrating OPT with
the block editor previously chosen Blockly, and also because in recent years
Python has been gaining traction as a preferred language for CS1 courses
across many universities, for its readable and friendly syntax. It is a web ap-
plication structured in two main components, a frontend and a backend. The
backend is written in Python and the frontend written using standard web
technologies: HTML, CSS, and JavaScript. The OPTutor backend takes the
source code of a Python program as input and produces an execution trace
as output. It executes the input program under supervision of the standard
Python debugger module (bdb), which stops execution after every executed
line and records the program’s run-time state. The default configuration
stops after 300 steps to prevent infinite loops, but it is a parameter that can
be personalized. The trace is an ordered list of execution points, where each

Eple thesis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Eple thesis

Semelhante a Eple thesis (20)

Mais de Pier Giuliano Nioi

Mais de Pier Giuliano Nioi (6)

Eple thesis