Department of Computer Science Master Degree in Computer Science
P101-lab
Design, development and field trial of a web-based
educational laboratory for teaching high school
students how to program the Olivetti Programma 101
Supervisor
Federico Poloni
Lucio Messina
Candidate
5 March 2021
Contents
1 Introduction 7
1.1 Programma 101 history . . . 7
1.2 Programma 101 technical overview . . . 8
1.3 Programma 101 Manual mode vs programming . . . 9
1.4 Programma 101 Programming language . . . 10
1.5 Critical aspects . . . 12
2 Simulator 15 2.1 Overview of existing simulators . . . 15
2.2 Refactoring . . . 17
2.3 Improvements . . . 18
2.4 Differences with the original Programma 101 . . . 18
2.5 User Interface and User Experience . . . 19
3 Block Language 23 3.1 Editor . . . 23
3.2 Language design . . . 25
3.3 Advantages of using a block language . . . 28
4 Didactic Laboratory 31 4.1 Laboratory description and aims . . . 31
4.2 Didactic Material . . . 33
4.3 Field Trial . . . 38
Abstract
The subject of this thesis is the design and development of an online simula-tor with a block-based programming UI for the Programma 101 (an hissimula-torical machine produced by Olivetti and considered by many the first desktop com-puter). We also prepared the material for the delivery of the lab as a lecture to high-school students or as self-study and tested it in a school.
Chapter 1
Introduction
This thesis is realized in cooperation with the Museum of Computing Instru-ments of the University of Pisa, its subject is the design and development of a web-based didactic laboratory to teach how to use and program the Pro-gramma 101, an historical machine produced by Olivetti and considered by many the first desktop computer. It is composed of a Programma 101 sim-ulator and a block-based program editor written in Typescript[Mic21b] and available online1. The framework used for the realization of the website is
Angular2[Goo21], the source code2 is available under the terms of the GNU
General Public License version 3[Fou07]. We also prepared some teaching material for the delivery of the lab as a lecture to high school students or as self-study; both the website and the teaching material are in Italian. We tried to improve the learnability of the Programma 101 usage and program-ming by paying particular attention to the user interface of the simulator and to the design of the block language. In this chapter we present a brief history and technical overview of Programma 101 and report some critical aspects of the machine that guided us in the realization of the laboratory.
1.1
Programma 101 history
The first prototype of Programma 101 was completed in 1964 by the Olivetti engineers Perotto, De Sandre and Garziera. They worked with a small group of engineers and technicians which was responsible for marginal electronics
1https://master-thesis-p101.bitbucket.io/
activities, as the main business of Olivetti at that time was producing and selling mechanical computers[Gua20]. Programma 101 was presented at the Business Equipment Manufacturers Association exhibition in New York in October 1965, achieving a great success: a total of 44.000 units were produced and sold, some of which were used by NASA to plan the Apollo 11 landing on the moon[Pro06]. Programma 101 memory is realized with magnetostrictive lines, a cheap and innovative technology for that time. The only ways to ”communicate” with the machine are a keyboard to type in the inputs and the program instructions and a printer that prints back the computation results. The machine is considered one of the first personal computers in history[ocwm19] (if not the very first) and it was designed such that it is easy to be used by everyone. Great attention was taken for the physical aspects (such as the exterior design and ergonomics) and the usability ones (such as the programming language design).
1.2
Programma 101 technical overview
The memory of the Programma 101 is composed of 3 operative registers (M,A,R), 5 storage registers (B,C,D,E,F) and 2 program registers (labeled as p1 and p2 in the manuals but not explicitly addressable). The user can input numeric data using the keyboard, all the typed numbers are stored in the register M. The machine is capable of computing the four fundamental opera-tions (sum, subtraction, multiplication and division), square roots, absolute values and the fractional part of a number. The operands for these opera-tions are taken from the register M (for the operaopera-tions with one operand only such that the square root) or A and M (for the operations with two operands), the results are truncated to a certain number of decimal places and memo-rized back into the register A. The complete result (i.e. the results with up to 15 decimal places) is stored in the register R. There are some exceptions to this general rule: for example when computing a division the remainder is stored in the register R rather than the complete result. The number of decimal places for the results to be stored in A can be chosen by the user by turning the so called ”decimal wheel”[Oli65a]. The storage registers are used as generic memory being capable to store a single 22-digits number (plus decimal dot and algebraic sign) each or they can be split to store two 11-digits number (plus decimal dot and algebraic sign) each. When a storage register is split, its first half is denoted by the same letter of the full register,
while the second half is denoted by the corresponding lowercase letter. For example, when the register B is split, the two halves are denoted by B and b. It is possible to move values back and forth from the operative registers to the storage registers in three ways: exchanging the content of any storage register with the content of A, copying a value from any storage register to A and copying a value from M to any storage register. Is it also possible to perform an computation using A and a storage value as operands: in this case the machine copies the value from the storage register into M and then performs the operation with A and M as usual. The machine is also capable to perform some ”service” operations: print a register value, print an empty line (vertical spacing), reset a register.
1.3
Programma 101 Manual mode vs
program-ming
In its simpler use Programma 101 can be operated manually as an electronic calculator. The user inputs the numbers using the numeric keys of the key-board and the command using the special keys of the keykey-board, specifying the operation to perform (computation, data transfer or service operations) and the involved registers. The machine can also be programmed by tog-gling a switch (RECORD PR) and using the keyboard to specify a sequence of commands to be stored in the machine memory (registers p1 and p2) rather than executed on-the-fly. The two program registers can store up to 24 in-structions each, for a total of 48 inin-structions. If the recorded program is longer, the instructions starting from the 49th onward are memorized in the registers F, f, E, e, D and d in this order: each half of a storage register used for the program can contain up to 24 instructions, in this way it is possible to store programs composed of up to 120 instructions in total. When only one half of D, E or F is used to store instructions it is possible to use the other half for the data, for example it is possible to write a program composed of 75 instructions (which will be memorized into p1, p2, F, f and E) and use e, D and d (as well as A and B, whole or split) for the data. Once the program is stored into the machine memory it is possible to run it pressing the S
key or to print it by toggling a switch (PRINT PR) and then pressing the S
key. It is also possible to save the program into a magnetic card, in this case the content of the registers D, E and F (either whole or split, either
contain-ing numbers or instructions) are saved on the magnetic card as well. When the same magnetic card is later reloaded into the machine the program is transferred into the memory along with the content of the registers D, E and F. This feature is referred by the manuals as ”storing constants” into D, E, F, because the numeric values loaded from the magnetic cards can be later read from the three registers and used as constants by the programs. It is possible to split programs longer than 120 instructions on different magnetic cards.
1.4
Programma 101 Programming language
The programming language of Programma 101 is a kind of assembler created appositely for this machine in which each instruction is a couple <register, operator>. register can be one of A, B, C, D, E, F, M, R, possibly followed by / to denote a split register (for example C/ is used to denote c); in some instructions register can be omitted, in this case the M register is selected automatically; / only is also sometimes accepted as registers for some special instructions. operator is one symbol that encodes the operation to be performed by the machine: it can be one of the four fundamental arithmetic symbols (+,× or :), the square root symbol √ or one of the symbols that encodes the service or data transfer operations (↕ for exchange with A, ↓ for copy to A, ↑ for copy from M, * for reset register and ⋄ for print). Example of valid instructions are <B,+> that copies the value of B into M and then sums A and M; <R,⋄> that prints the value of the register R and <F/,↑> that copies the value of M into f. Some combinations <register, operator> have a special meaning, for example: <A, ↕> computes the absolute value of A (rather than exchanging A with itself which would not be useful); </, ⋄> prints an empty line. It is worth noting that these instructions can be stored into the machine memory to compose a program, but it is also possible to execute them on the fly when using the manual mode of Programma 101. In both cases the instructions encoding is the same, for example pressing the key R followed by the ⋄ key while the machine is running in manual mode will result in printing the value of the register R.
Some other kinds of instructions can be inserted into the programs and are not effective when using the machine in manual mode. These are the halt instruction, the jump instructions, the constant coding instructions and the RS instruction.
Halt instruction The halt instruction (coded as <,S>) halts the program execution and waits for the user input. It is actually possible to perform any kind of operation while the machine is halted rather than just typing the input, for example modifying the register values or inserting a different magnetic card. Afterwards the user can restart the program by pressing the
S key: the execution continues from the next instruction.
Jump instructions The jump instructions are used to transfer the control flow of the program to another instruction, they are similar to the jump in-structions in the modern assemblers inin-structions set. The jump inin-structions use the letters V, W, Y and Z as operators. To perform a jump the program-mer must specify two instructions: the instruction from which the jump is taken (called ”point of origin”) and the instruction from which the execution continues after the jump is taken (called ”reference point”)[Oli65a]. There are two kinds of jump: unconditional jumps and conditional jump, both having 16 different pairs of origin-reference points. All the instructions for unconditional jump are encoded with full registers (for example the pair <,V> (origin) and <A,V> (reference)) while all the instructions to perform condi-tional jumps are encoded with a split register (for example the pair </,V> (origin) and <A/,V> (reference)). When the origin point of an unconditional jump is to be executed, the machine seeks the corresponding reference point in the program and the execution continues from the instruction following it. When the origin point of a conditional jump is to be executed, the value of the register A is checked: if it is greater than zero the machine seeks the reference point and the execution continues from the instruction following it, otherwise the execution continues normally from the instruction follow-ing the origin point. Each reference instruction can be used only once in the same program, although is possible to use the same origin instruction multiple times in the same program. After a program is loaded into the ma-chine or after an halt instruction, the execution can be (re)started from one of the four unconditional references point <A,V>, <A,W>, <A,Y> or <A,Z> by pressing one of the label keys V , W , Y or Z respectively. This feature is particularly useful to save many different ”subprograms” into the same magnetic card, each of them being activated manually by the user pressing one of the label key. Furthermore, many existing programs for Programma 101 start with the instruction <A,V>, read the input using an halt instruc-tion, perform some computations and end with a <,V> instrucinstruc-tion, effectively
creating a loop so that the user can run the same program multiple times without restarting it.
Constant coding instructions The constant coding instructions are se-quences of instructions that start with <A/,↑> and encode constants to be stored in register M. Each coding instruction encodes four pieces of informa-tion: one digit of the constant, the sign of the constant, whether or not that digit is the last one and whether or not that digit is the unit digit. The used encoding is a sort of BCD (binary coded decimal) and it is the same format used internally by the machine to store the register values. When the instruction <A/,↑> is to be executed, the machine reads the following instructions and decodes the constant value digit by digit until the instruc-tion that encodes the last digit is found, then it stores the constant into the register M[Oli65b].
RS instruction the RS instruction simply exchanges the content of D with the content of R. It is only useful when running a program memorized into multiple magnetic cards: since the registers D, E and F are overwritten each time a magnetic card is read (section 1.3), the partial results computed by the instructions on a card can only be saved into A, B and C. Using RS as the last instruction of a magnetic card allows to save one more partial result into R before inserting the next magnetic card. That value should be copied back into D by another RS instruction on the second magnetic card before any arithmetic operation that would change the value of R.
See table 1.1 For the complete instruction set of Programma 101 and instruction encoding.
1.5
Critical aspects
Programma 101 was advertised as simple and usable by anyone[Oli66]. Its programming language is simpler than the ones of the earlier computers, for example programming the Olivetti ELEA 9003 (1959) required to know the binary coding of the instructions and the memory addresses for the jump instructions[Oli59]. Furthermore, the use of magnetic cards allowed everyone to run any program without even knowing the programming language, while early computers ”could only be used by experts” [Oli66]. This was certainly
Category Instruction encoding arithmetic sum <X,+> subtraction <X,-> multiplication <X,×> division <X,:> square root <X,√> decimal part of A in M </,↕> absolute value of A <A,↕>
data transfer copy from M <X,↑> copy to A <X,↓> exchange with A <X,↕>
service halt for input <,S> reset register <X,*> print register value <X,⋄> vertical spacing </,⋄>
jumps unconditional jump <,∆> → <A,∆> <C,∆> → <B,∆> <D,∆> → <E,∆> <R,∆> → <F,∆> conditional jump </,∆> → <A/,∆>
<C/,∆> → <B/,∆> <D/,∆> → <E/,∆> <R/,∆> → <F/,∆>
special constant coding <A/,↑> exchange D and R <R,S>
Table 1.1: The complete instruction set of Programma 101 and instruction encoding taken from the programming manual ([Oli65b]). X is a placeholder for ”any register”, ∆ is a placeholder for the labels V, W, Y, Z. The jump instructions pairs are reported in the form origin → reference.
true in the 1960s, where an expert scientist could learn how to use the Pro-gramma 101 in short time. Nowadays the programming standards are very different: we have higher level programming languages and learn how to use the Programma 101 can be difficult to learn even for computer scientists, let alone for novices. The Programma 101 instruction encoding is better than binary but still not easy to remember; the control flow of the program is hard to follow because the association between origin and reference points in the jump instructions is not immediate. Apart from the programming language not being abstract enough, some other aspects of the machine make it rela-tively difficult to learn, like the lack of knowledge of the register values while using the machine in manual mode and while debugging a program. When a program is being recorded it is only possible to clear the last instruction, so if the user realizes they made an error before the last instruction they have to start recording the program from scratch. Finally, when an error occurs during the program execution the only indication is a red light turning on. We decided to address these issues while designing our Programma 101 sim-ulator (see chapter 2) and program editor (see chapter 3) by providing a friendly environment for novice learners while preserving the historical accu-racy of the executed operations.
Chapter 2
Simulator
The simulator component of our laboratory is a fully featured Programma 101 simulator, it can be found on the simulator tab of the website. We developed it starting from another simulator created by the University of Cassino: in this chapter we report an overview of the existing simulators, we explain the phases of the development and show the User Interface and User Design choices we made.
2.1
Overview of existing simulators
Before developing a Programma 101 simulator from scratch we searched for an existing implementation to be used as starting point for our work. Table 2.1 shows the results of our research.
The first thing we noticed is that only one simulator is Open Source, the other ones have no license attached and in some case the source code is not available. Furthermore, many of the listed simulators require to download and install some sort of software to be executed: as pointed out in [BGK+17],
this may penalize novice users and a fully available online software should be preferred. For this reasons we believe that the most suitable choice for our needs is the simulator developed by the University of Cassino[dC16]: it was written in cooperation with Giovanni de Sandre, one of the creator of the Programma 101, so it is also historically very accurate. We managed to solve the issue of not having an attached license by simply asking the authors for permission to reuse their code base: they agreed as long as we quote them as the developers of the first simulator version. The source code
Dev elop er(s) Y ear W ebsite Programming language License Larry Smith ? do wnload n.d. (Windo ws executable) n.d. (source co de not av ailable) Marco Galeotti ? not w orking E.H. Do oijes 1995 do wnload turb o pascal n.d. Claudio Larini 2008 do wnload Quic k Basic n.d. (source co de not av ailable) T ecnologicamen te Museum 2014 do wnload ja va n.d. Claudio Vianini 2016 do wnload Microsoft Excel n.d. n.d. 2017 do wnload tcl tcltk license (BSD lik e) Univ ersit y of Cassino 2017 a v ailable online ja v ascript n.d. T able 2.1: Ov erview of existing Programma 101 sim ulators. W e used the one dev elop ed b y the Univ ersit y of Cassino as sta rting p oin t for our lab oratory . 16
of our whole laboratory (including the simulator) is released under the GNU General Public License version 3[Fou07]. The code of simulator developed by the University of Cassino constitutes the core of our website and it is henceforward referred as the ”original” simulator.
2.2
Refactoring
The original simulator has a good historical accuracy as it achieves almost always the same results of the original machine both when used in manual mode and when running the programs. For this reason we tried to modify the original source code as little as possible: the only three changes we made are the porting of the existing code base in Typescript, a major behavior-preserving refactoring and some small bugfixes. We decided to switch the programming language not only because Typescript is the default program-ming language for Angular 2 applications but also to create a set of interfaces and type definitions for the manipulated objects (such as instructions, reg-isters, the machine status and many more) to ease the next development phases and with the hope that it will be useful for future modifications. The refactoring was necessary because the original simulator code mixes the model logic with the view and control logic a lot, for example by manipu-lating the Document Object Model directly to show the effects of an user input or by using the window.alert() function to show the errors. It also makes use of global variables accessible from different functions to memorize the state of the machine. We created a self-contained class that implements the simulator and whose methods correspond to the actions that is possible to perform to interact with the machine (for example pressing a key, chang-ing the number of decimal places or insertchang-ing a magnetic card). The class exposes the status of the machine: the register values, the printer output and whether or not there was an error; other parts of the application are in charge of modifying the view according to the current status of the machine. Is it worth noting that our implementation of the simulator has no external dependencies (it does not even require the Angular runtime to be used), so it is possible to move it to other projects if needed. With this settings we were able to write a comprehensive suite of unit tests for all the features of the machine to ensure the behavior of the simulator is the same as the one of the original machine. By running these test we discovered some minor bugs in the original simulator (such as not computing the remainders of the
divisions correctly, rounding instead of truncating, and resetting the register R which is not possible in the original machine): these bugs were corrected in our version of the simulator.
2.3
Improvements
The original simulator encodes the instructions using a triplet <constant, register, operator>. This encoding is different from the one of the original Programma 101 that uses the couple <register, operator>, as described in section 1.4. We don’t know the reason of this choice, our best educated guess is that this simplifies the handling of constant coding instructions: the constant to be stored into the register M is read from the instruction <A/, ↑> instead of decoded digit-by-digit from the following instructions: the original simulator does not even implement the decoding logic. Saving constants in the instructions also simplifies the process of storing constants into magnetic cards (see section 1.3) and allows to use the same data structure to memorize instructions and printed lines. When developing our simulator we switched to the ”correct” instruction representation and implemented the constant decoding logic. Our simulator is backward compatible being still capable of parsing the files containing programs written using the original simulators.
The original simulator simulates the execution of the Programma 101 programs in the main Javascript thread, which is not the best choice because it also controls the user interface: the webpage can freeze if the execution of a program requires a long time to complete or if the program contains an endless loop. We implemented the possibility to execute the Programma 101 programs into a Web Worker[Gro21] that runs in a different Javascript thread. After a batch of instructions are executed, the Web Worker posts the register values and the printer output to the main thread, that updates the user interface: in this way the users can interrupt the program if it is running for too long.
2.4
Differences with the original Programma
101
There are some small differences between our simulator and the original ma-chine, mostly regarding the program storage. The memory of the simulator
is not capped to 120 instructions: is it possible to write programs with vir-tually any length1. For this reason the instruction are never written on the
registers D, E and F, which remain available for storing data regardless of the length of the recorded program. In the original simulator implementation there was no limit to the program size as well and we did not introduce it.
Another difference between our simulator and the original P101 is that it is not possible to store constants into D, E and F when saving a program into a magnetic card (see section 1.3). The original simulator is able to store constants, but it uses a sequence of special instructions each one containing the constant, the register and a non-existent operator store: as explained in section 2.3 the original simulator instructions contain constants. Since we removed the constants from the instructions we were not able to use the same method as the original simulator to store the constants, and since the program size is unlimited it is not possible to segment the magnetic cards content into p1, p2, D, E, F to retrieve the constants to be stored into D, E, F. For these reasons we decided to remove the possibility to store constants into D, E, F but we plan to reintroduce it in the future. Anyway, this is not an essential feature because it is possible to generate the constants into the register M.
Finally, there is one missing feature in our simulator: while using the the original Programma 101 in manual mode it is possible to input a constant and then press the key A followed by ↑ . The machine prints the instruc-tions that encode that constant to be used in a program after the <A/, ↑> instruction (see section 1.4). This feature was not implemented in the origi-nal simulator, however it is possible to generate the same sequence directly while recording a program by typing the constant and then pressing the keys
A / ↑ . The machine records the <A/, ↑> instruction followed by the instructions that encode the constant. We did not change this behavior since it is not different from how the original machine works and it simplifies a bit the process of recording the programs.
2.5
User Interface and User Experience
We paid particular attention to the graphical user interface and user experi-ence of our simulator because we think it can ease the process of teaching a
1of course the actual program size is limited by the maximum size of the Javascript
complex subject such as the Programma 101 usage.
The simulator tab is composed of two parts: the left part shows the keyboard of the Programma 101 and a slot for the virtual magnetic cards, while the right part shows a panel with the printer and the register values and a panel with the recorded magnetic magnetic cards (see figure 2.1). In the original Programma 101 the lights and the printer are located above the keyboard, next to the slot for the virtual magnetic cards, thus our view is historically not accurate. In our very first design the components were correctly placed, but then we realized that the lights and the printer output have to be dis-played in our block program editor too (see section 3.1), so we chose to show all the ”output components” on the right and to reuse the same view in the editor tab to avoid confusion for the users.
Showing the register values is useful for novice users to see the status of the machine after every instruction rather than rely only on the printer output. We organized the register view placing the storage registers above the operative registers A, M, R, with three arrows (↕, ↓ and ↑) displayed in the middle, the first two being above A and the last one above M (figure 2.2). In this way it is simple to remember the meaning of the symbols for the data transfer commands (section 1.4): the ↕ command exchanges the value of a general register (above) with the value of A (below), the ↓ command copies a value from a general register (above) into A and the↑ command copies the value of M (below) into a general register (above). In other words, if the users pretend that the registers are physical entities filled with physical values and arranged as shown in our simulator, when the data is moved or copied from a register to another by the instructions it follows the directions of the arrows. We show a gray box as a placeholder for an arithmetic operator between A and M to remind the order of the operands in a computation, which is A op M with op being +, x, - or :. The operator of the last arithmetic instruction executed is shown in the gray box. When a register key is pressed, its box is highlighted to avoid errors in selecting the wrong register for an instruction; when the value of a register changes due to an instruction its box flashes for a few seconds to show the effects of that instruction. Split registers are not shown until they are used: this helps to reduce the cognitive load for the novices by introducing the concept of split register only when they are ready to learn it. When a register is split, its two halves are shown at the same place where the full register originally was and take up roughly the same room (figure 2.2).
It is possible to input numbers and commands by clicking on the
Figure 2.1: The simulator tab graphical user interface
screen Programma 101 keyboard or by using the physical keyboard, this will make skilled users faster in using the machine. When a program is recorded, a virtual magnetic card is created: all the created magnetic cards are shown on the right panel. It is possible to load the virtual magnetic card into the machine or save the program into a file (see figure 2.3). When an error occurs during the execution of a program not only the red light turns on, but also a meaningful message is shown to the user: this should help novice users to debug their programs faster.
Figure 2.2: Registers visualization in the Programma 101 simulator.
(a) A magnetic card loaded into the simulator
(b) All the recorded magnetic cards are shown in a panel on the right
Figure 2.3: Virtual magnetic cards can be recorded using the simulator, saved into files, loaded from files, deleted, loaded in the simulator and modified in the editor tab
Chapter 3
Block Language
We decided to create a block language to overcome some of the critical aspects of Programma 101 reported in section 1.5. We implemented an editor for that language using the Blockly library that provides an off-the-shelf editor to represent coding concepts as interlocking blocks[Dev20]: to use the editor the users have to switch to the editor tab of the website. In this chapter we describe the editor features, we explain the design of the block language and we discuss the advantages of using such language rather than the original one.
3.1
Editor
The editor component of our laboratory can be used to create programs for Programma 101 using the block language rather than registering the instruc-tions using the keyboard of the machine as described in section 1.3. It is sim-ilar to many block language editors available online and widely used to teach computational thinking and computer science such as Scratch[RMMH+09]
and App Inventor[DASL11] because we wrote it using the very same tech-nologies. The editor is composed of a toolbox that shows all the available blocks and a block area in which the blocks can be dragged to compose the programs (see figure 3.2).
The programs written using the editor can be saved into virtual magnetic cards, it is also possible to edit the magnetic cards previously recorded using the simulator. The editor tab allows to execute the program represented by the blocks directly and to execute just one instruction of the program at a
Figure 3.1: The programma 101 program editor graphical user interface
time (step-by-step execution): in the latter case the block corresponding to the instruction being executed is highlighted to provide a visual feedback of the control flow of the program, which is useful for novice programmers, following the good practice suggested in [BGK+17]. The value of the
Pro-gramma 101 registers and the printer output are also shown using the same layout described in section 2.5 to allow the user to track the machine sta-tus during the execution of the programs (see figure 3.1). Although in most existing block language editors the program state is visible during the exe-cution of the program (for example it is possible to show the variable values in Scratch), the ability of executing the program step-by-step is a rather innovative feature. Scratch had something similar called ”Single Stepping” in version 1.0 but it was removed in the later versions[Tea20]. Micro:bit makecode[Mic21a] has a debug mode that allows to set breakpoints and exe-cute the blocks step-by-step but it does not allow editing the code while the debug mode is activated.
When an halt instruction is to be executed, the program stops, the block cor-responding to that instruction is highlighted and a small keyboard appears next to it (see figure 3.3). The keyboard only contains the digits key, the
S key, the algebraic minus key and the decimal dot key as its designed to let the user input a number and then restart the machine. However, it is
Figure 3.2: Block editor. All the available blocks are show in the toolbox on the left and can be dragged to the program area on the right
possible to switch to the simulator tab to execute any other operation while the machine is stopped on an halt instruction (see section 1.4).
3.2
Language design
We decided to include one kind of block in our block language for each kind of instruction in the Programma 101 programming language with two excep-tions: we did not include the RS instruction (which exchanges the values of the registers D and R) and we designed a single block for a sequence of con-stant encoding instructions. Since there are five categories of instructions in the original programming language (see table 1.1) we created five categories of blocks as well: arithmetic, data transfer, service, jump and special. The standard Blockly palette includes some blocks for structured programming
Figure 3.3: The execution is stopped on an halt instruction: the keyboard ap-pears. Note that there are many halt instructions, but only the one requiring the input is highlighted
(if, while, the boolean operators...), so we had to define our custom blocks by configuring the appearance, the wordings, the connections and the inputs for each block. In the Blockly jargon the inputs of a block are its parameters, which can be chosen by the user after placing the block. There are a lot of available kinds of input: text, number, dropdown, date picker and many other; for example the block "random integer from l to h" from the stan-dard Blockly palette has two inputs: l and h, both of them of type number. For the colors of our blocks we used the same scheme of the keyboard of the original Programma 101: the blocks from the same category have the same color as this helps the programmers to find them more quickly as suggested in [PFM17]. We choose the wordings avoiding jargon: the blocks show a sim-ple natural language sentence such as "multiply by M" or "compute the
absolute value of A" so that the users can focus on the semantics of the programs rather than their syntax as discussed in [BGK+17]. Since there
is no structured programming constructs, all the blocks have a rectangular shape with the top and bottom connections to be chained with the other blocks. As for the inputs, the blocks that correspond to fixed instructions have no input because there is nothing to choose: for example the block "compute the absolute value of A" that is equivalent to the instruction <A,↕> (see section 1.4). Most blocks allow the user to chose a register to operate on, for example the block "copy M to X" that is equivalent to the instruction <X, ↑>, where X is a register. These blocks have only one input dropdown showing the possible registers as options: it is worth noting that not all the registers can be chosen for all the block types, for example the options for X in the block "exchange A with X" does not include A, other-wise the instruction <A, ↕> would be generated when translating that block into the Programma 101 language. The register M is the default option for all these dropdowns, since the register M is also the default for the instructions without register. One single block "put t into M" can be used instead of the sequence of instructions that encodes the constant t: that block has a text input field in which the user can type the value of t.
We simplified a bit the blocks representing the jump instructions by using numerical labels instead of the origin-reference pairs (see section 1.4 for an explanation on how the jump instructions work in the original language); these labels are referred in the source code as fakelabels. There are 16 fakela-bels (the numbers from 1 to 16) for unconditional jumps which can be set in the program using the block "this is point l" where l is a number from 1 to 16. The jump origin instruction is represented by the block "jump to point l". There are also 16 fakelabels for the conditional jump instructions: these labels have the form C1, C2 ... C16 and can be set in the program using the block "this is point c" where c is one of C1, C2, ... C16. The conditional jump origin is represented by the block "if A>0 jump to point
c". This encoding is simpler to remember because the fakelabel is the same in both the origin block and the reference block: for example the users of the block language will use the blocks "this is point C14" (reference) and "if A>0 jump to point C14" (origin) rather than the instructions <F/,W> (reference) and <R/,W> (origin), that requires to memorize not only the as-sociation between the registers F and R, but also which one is the reference and which one is the origin. There are four kinds of jump blocks, each of them having a single dropdown to select the fakelabel. See table 3.1 for the
complete set of available blocks.
Blocks translation The programs written using the block language have to be translated to the original programming language in order to be executed or saved into virtual magnetic cards. Since each block corresponds to one Programma 101 instruction the translation is straightforward: a sequence of blocks is translated by concatenating the output of the translations of the single blocks. The blocks that correspond to fixed instructions are trivially translated with the represented instructions. The blocks in which a register has to be chosen are translated by taking the operator from the kind of block and the register from the chosen option: for example a block "sum
F" (i.e. a block of the kind "sum X" where the user has chosen F from the dropdown) will be translated with the instruction <F,+>. The block ”put t in M” will be translated with the instruction <A/,↑> followed by the sequence of instructions that encode t: this is the only case in which multiple instructions of the original language correspond to a single block. A pair of instructions origin-reference is associated to each one of the 32 fakelabels: the blocks "this is point l" are translated with reference instruction corresponding to l, while the blocks "jump to point l" and the blocks "if A>0 jump to point l" are translated with the origin instruction corresponding to l. For example, the instructions <F,W> (reference) and <R,W> (origin) are associated with the fakelabel 14. The block "this is the point 14" is translated with the instruction <F,W>. See the last column of table 3.1 for a summary on how the blocks are translated.
3.3
Advantages of using a block language
As discussed in section 3.2, the blocks replace the original instruction encod-ing with a friendlier natural language sentence, makencod-ing the programs easier to read and the execution control flow easier to follow: [WW15] claims that this holds for the block languages in general. This is not the only advantage of using a block language: it also reduces the cognitive effort of the users because all the available blocks can be retrieved from the toolbox on the left while the instructions must be memorized. The benefits of block recogni-tion versus instrucrecogni-tion recalling are discussed in [WW17], and since in our language there are relatively few blocks it is possible for new users to know what the machine is capable of at first glance. Also, using the blocks the
Category Blo ck P ossible v alues translation arithmetic sum X X is M , A , R , B , C , D , E or F <X,+> subtract X X is M , A , R , B , C , D , E or F <X,-> multiply by X X is M , A , R , B , C , D , E or F <X, × > divide by X X is M , A , R , B , C , D , E or F <X,:> square root of X X is M , A , R , B , C , D , E or F <X, √ > decimal part of A </, ↕> absolute value of A <A, ↕> data transfer copy M to X X is B , C , D , E or F <X, ↑> copy X to A X is M , R , B , C , D , E or F <X, ↓> exchange A with X X is M , B , C , D , E or F <X, ↕> service halt for input <,S> reset X X is A , B , C , D , E or F <X,*> print X X is M , A , R , B , C , D , E or F <X, ⋄> vertical spacing </, ⋄> jumps this is point l l is 1 , 2 , 3 ... 16 a conditional reference instruction dep ending on l jump to point l l is 1 , 2 , 3 ... 16 a conditional origin instruction dep ending on l this is point l l is C 1 , C 2 , C 3 ... C 16 a unconditional reference instruction dep ending on l if A>0 jump to point l l is C 1 , C 2 , C 3 ... C 16 an unconditional origin instruction dep ending on l sp ecial put t in M t is a constan t <A/, ↑> follo w ed b y the instructions that enco de t T able 3.1: The av ailable blo cks in our blo ck language. The column p ossible v alues sho ws the p ossible options for the input of the blo ck (if an y). The column translation sho ws the equiv alen t instruction in the original language
users can create a portion of a program, test it and then integrate it into the main program, which is not possible to do when using the original language. The editor also solves some critical aspects specific to the Programma 101 usage: for example it is possible to edit any part of the program rather than only the last instruction. Also, when a program stops, the block correspond-ing to the last executed instruction is highlighted: in this way the user can see at which point of the program an error occurred or what instruction is requiring an input (see figure 3.3). This is substantially better than using the original Programma 101 (or the simulator) in which the user has no feedback on the instruction being executed.
[WW17] also reported that those who learned any block language in the past may have an advantage in using other block languages: in our particular case we expect the students that are used to write programs with Scratch to learn how to program the Programma 101 faster. Many other advantages in using the block languages can be found in literature, some of which are not applicable in our case, for example the possibility to compose the instructions to create syntactically correct programming constructs, which we don’t have because the Programma 101 language is a kind of assembler and it does not allow instruction composition.
Chapter 4
Didactic Laboratory
We developed the Programma 101 simulator (chapter 2) and the block editor (chapter 3) to use them for a didactic laboratory to teach programming on various levels. Despite being originally thought for high-school students, we plan to prepare some additional teaching material to deliver the laboratory to a wider audience, like computer science freshmen or middle-school students. In this chapter we describe the laboratory, we present the used didactic material and we report a field trial we conducted on a class of high-school students.
4.1
Laboratory description and aims
We believe that Programma 101 has some interesting features that make it particularly suitable for teaching computer science. First of all, as pointed out by [CG13], old machines are simpler to understand than the modern ones because they are built on a human scale and understandable in all their details. Furthermore, Programma 101 has a small instruction set that makes immediately obvious for the user to know what is possible to do and forces them focus on how to solve the problem at hand by combining the available instructions rather than by searching for a complex instruction to use. Most importantly, Programma 101 has the so called ”manual mode” (see section 1.3), using which it works as an electronic calculator: everyone has most likely used an electronic calculator in their lifetime, even who is a complete novice to programming. The fact that the Programma 101 instructions used in manual mode are the same as the ones of the programming language offers
the opportunity to introduce programming as ”the act of concatenating a sequence of instructions that will be executed autonomously by the machine in succession”, which is indeed a good definition if we ignore jumps and user inputs.
This is exactly what we planned to do in our laboratory with novice users: we first use the simulator to teach how to use Programma 101 in manual mode, explaining just the basic concept like the storage of data in the register, how the computations are done and the data transfer operations. In this phase, the users became confident with some peculiarity of the machine, like the fact that input numbers are always stored in the register M and the fact that the operations always involve the registers A and M. Students are given some mathematical challenges and encouraged to compute the results independently using the Programma 101 simulator. Then we move to the editor to explain what programming means, showing a simple block program that solves one of the problems presented as challenge earlier. In this way the students can see how a program is just a sequence of instructions that they could have run by hand or using the machine in manual mode. Then we move forward explaining some advanced topics like conditional and unconditional jumps.
If the students that participate to the laboratory had no prior exposure to computer science, after the activities they will at least understand what is programming, what are the typical instructions of a low-level programming language and how do the computers execute them. They will also learn the history of Programma 101 which is unknown or forgotten by most.
The laboratory can also be delivered to students have experience with programming, in this case it can be considered as a nice introduction to low-level programming: those students already know what programming is, but they have always used high-level structured programming as the assemblers language is often not studied in depth in high-schools in Italy. It is worth noting that the block language we designed (chapter 3) is perfectly suited for this aim: there is just one kind of rectangular block corresponding to instructions that can be chained but not composed, just like the modern assembler instructions. This is a quite unique feature for visual programming languages: to our knowledge all the other block languages have blocks that correspond to structured constructs. When the audience is composed of students that are already familiar to computer science, we present different challenges to the students, for example how to implement the if-then-else construct or how to implement a conditional jump whose condition is not
just the value of register A being positive but an arbitrary condition. In this case the aim of the laboratory is to explain the assembler instruction set and to introduce the concept of compilation: we point out that many low-level blocks are equivalent to a single block of a traditional block language (such as Scratch) and that even the behavior of a C-shaped blocks can be implemented using a combination of low-level blocks (see figure 4.1).
(a) (b) (c) (d)
Figure 4.1: Comparison of two programming constructs implementation: composite computation A = A+B*C in Scratch (a) and using the Programma 101 blocks (b); if-then-else using the apposite block in Scratch (c) and using Programma 101 blocks (d) –the blue joint on the left is only shown to em-phasize the shape generated by the composition of the four blue jump blocks, which is the same shape of the if-then-else Scratch block. The Scratch ex-amples use variables while the Programma 101 exex-amples use the registers
4.2
Didactic Material
The simulator and the block program editor are not easy to use for those who don’t know the Programma 101, thus some sort of explanation is necessary to enjoy the laboratory. Typically there will be a tutor that explains the concepts to the students, assigns the challenges and provides feedback on the exercises solutions. We also plan to develop an interactive version of the website in which the explanations and the exercises are loaded dynamically from a database depending on the audience and the solutions are automat-ically checked: this is possible to implement because of the refactoring we made to the simulator source code (section 2.2) but it is out of the scope of this thesis. For now we just prepared some slides to deliver the laboratory as a lecture for high school students: the slides are are in Italian and con-tain explanations, screenshots from the simulator and the editor interface,
exercises and programming ”recipes”, that are descriptions of methodologies useful to solve recurrent problems. The slides are divided into five parts: introduction, manual mode, programming, conclusions and bonus materials. In this section we report the content of the didactic material; we also show some key slides surrounded by a green border.
Introduction In this part we explain what is Programma 101: we start with a little historical overview and then we present the capability of the machine. We also provide a link to the simulator so that the participants can open it and use it during the lecture.
Manual Mode In this part we explain how to use Programma 101 in manual mode. We point out that the memory of the machine is divided into registers (explaining what a register is) but we only use the operative registers A, M and R at first. We explain that the computation are always performed using the registers A and M as operators and we show how to perform simple calculations by typing the first operand, pressing the ↓ , typing the second operand, pressing the operator key (see figure 4.2a). We then explain the operation of the register R and we assign some exercises for the students on basic and chained computations. Afterwards we assign a different exercise (figure 4.2b): ”A farm buys 420 tons of corn (whose cost is 208.33€/ton) and 296 tons of rice (whose cost is 450.11€/ton). How much do they spend in total?”. This exercise is basically asking to compute the quantity ab + cd given the constants a, b. c and d, which cannot be computed using only the arithmetic instructions of the Programma 101: the straight-forward method would be to compute the partial result ab first, memorize it somehow, compute cd and then sum the previously memorized quantity
ab. We let the participant try to solve this task autonomously, expecting
that they will memorize ab by heart, write it down somewhere or rely on the printer output and then re-input it into the register M to compute the last sum, then we explain how to use the general registers to memorize the partial results avoiding transcription errors.
Programming In this part we explain to the audience what programming
means. We start by presenting a continuation of the previous exercise in which the farm buys different quantities of cereals every day and needs to keep track of the total expenses: in this scenario it would be convenient
(a) performing a sum using Pro-gramma 101 in manual mode.
(b) exercise that requires to memo-rize a partial result.
Figure 4.2: Two slides presented to explain the Programma 101 manual mode.
if the instructions were somehow registered so that the users only need to input the data and the machine will print out the total expenses. We explain that a program is nothing more than a memorized sequence of instructions and show a program that solves the problem at hand, implemented using the block language (figure 4.3a). Then we expand this basic definition of programming by presenting a few more topics:
• unconditional jumps, at first only used to create a loop around the whole program that makes it run forever without needing to be restarted (see section 1.4 and figure 4.3b);
• conditional jumps with standard condition, illustrating how they work and asking for a method to implement two mutually exclusive se-quences of instructions based on the content of the register A. We pro-vide a wrong reference solution (figure 4.3c) and we ask the participant to figure out why that solution does not work and to provide a correct recipe (which combines a conditional jump and an unconditional one, see figure 4.3d);
• conditional jump with arbitrary condition: the last challenge of this part is how to implement a jump based on whether the value of A is bigger than a value different from zero. Like before, we let the students think and implement a solution and then we show our recipe.
(a) The first program shown in the laboratory
(b) Using unconditional jumps to cre-ate a simple loop.
(c) A wrong proposed solution to im-plement two mutually exclusive se-quences of instructions
(d) The correct way to implement two mutually exclusive sequences of instructions.
Figure 4.3: Four slides presented to explain how to program the Programma 101.
Figure 4.4: Comparison of two implementations of the same program: the one on the left uses the block-based language while the second one uses the original Programma 101 language
Conclusions In this part we wrap up the covered topics of our laboratory,
adding a few words on the fact that the modern hardware is not much dif-ferent from the Programma 101 one. Finally we show a comparison of the block-based language versus the original one (figure 4.4), pointing out that each block is equivalent to an instruction in the Programma 101 language (see section 3.2) and that we created the block language just to ease the pro-gramming experience, but in the end the participants actually learned how to program the original machine.
Bonus material in this part there are some other topics not covered during the lectures due to the lack of time, but it can be used autonomously by the interested students:
• magnetic cards we explain how physical magnetic cards are used to store programs in the original machine (see section 1.3) and how to use the virtual magnetic cards for the same purpose;
• determined loops we provide a recipe to repeat the same sequence of instructions a fixed number of times, implementing the construct called ”for loop” in higher level languages;
• more challenges we present a lot of other challenges, the hardest one being to write a program that tests a given input number for primality. We designed the didactic material to cover lectures that will be one hour or one hour and a half long, but because of its modularity a different amount of topics can be covered depending on the receptiveness of the students: if
they struggle in understanding some concepts the tutor can slow down and present less material; on the contrary, if the students are interested and highly receptive the tutor can present the bonus material too.
4.3
Field Trial
We tested our laboratory with a class of 23 students enrolled in the fourth year of an High School in Pisa (Liceo Scientifico opzione scienze applicate). Due to the restrictions related to the Coronavirus pandemic the laboratory was held online through a videoconference: the tutor presented the didactic material described in section 4.2 while the students had one computer each and used the Programma 101 simulator and program editor described in chapters 2 and 3. The students are enrolled in a scientific curriculum in which they study computer science for two hours a week, so they can already program in C++ and Python and they used Scratch in the past. This trial can be considered a beta test which aims to detect any issue in the laboratory website or in the teaching material, in particular we wanted to check if the simulator interface works well for beginners and if the block language is simple enough to learn.
We are satisfied with the outcomes of the field trial: the students paid attention for the entire duration of the laboratory, they asked many questions and solved the exercises correctly. When we presented the exercise about the farm buying two different cereals we wanted them to solve it by themselves, expecting them to use a procedure like the one described in section 4.2 and then to explain the use of general registers and data transfer operations. One of the students solved that exercise correctly using the general registers and data transfer operations without waiting for our explanation. They said that they just looked at ”the arrows” to figure out what keys had to be pressed to transfer data from a register to another, hinting that our design choices for the interface are sound (see section 2.5). At the end of the session we left some room for the questions: the students were interested both in the technical part and in the historical one, and this gave us the opportunity to deepen some aspects regarding the differences between programming the original machine and using the simulator, for example the lack of feedback from the original machine and the differences between the original programming language and the block one.
The field trial also brought to light some opportunity to improve the
oratory. First of all we noted that the timing was not perfectly balanced: even if the participants were highly receptive and already familiar with com-puter science, we struggled to present all the material; we only had time to explain the topics up to the unconditional jumps and just a few words on the conditional jumps and compilation. This issue was mitigated in part by the modularity of the teaching material: we just skipped the last few slides of the programming part. Another issue was that the topics of the presented exercises were too abstract for students of that age: most exercises are about financial calculations, we will revise them soon.
We prepared an anonymous questionnaire to collect some feedback: it was filled in by 10 students so the results are not statistically significative, but we report them anyway because we think they can give some insights on how the laboratory was received. The first part of the questionnaire is composed of five questions to be answered using a scale between 1 and 10: the first three are about the perceived difficulty of: using the Programma 101 in manual mode, programming the original machine and programming using the block editor. The fourth question asks about how ”powerful” is perceived the block language with respect to the original programming language: by ”power” we refer to the set of things that can be computed using the two languages as discussed in [WW15], the answer 1 being ”the original language is more powerful” and the answer 10 being ”the block language is more powerful”. The fifth question simply asks for an overall rate on the laboratory.
The students appreciated the laboratory: the overall rates on the laboratory were between 8 and 10. As expected, they perceive the original machine as very difficult to program (all votes are lower than 6) and the manual mode and bock language much simpler (votes from 7 to 9 with only two exceptions). They also perceive the block language as being more powerful or equal to the original language, this may be caused by the difficulty to implement even a simple program using the original instructions: the two language are in fact equivalent.
After the rating questions there is one more optional ”free text” question that asks for a comment on the experience of programming the Programma 101 and if something was not clear. All the students except for one replied to this question, confirming that they enjoyed the laboratory. Many of them wrote that they are impressed by how the technologies evolved in only 60 years, judging the present computers more ”user friendly”. One of them wrote ”I think that with block programming is much simpler mostly because we used Scratch in the past years...”: this confirms our expectations and the
ones reported in [WW17]. The student continues: ”...at the same time it is very difficult without the block programming because the commands are complex and there is nothing that shows you what you are writing”. This is an important observation about the lack of feedback of the original machine that we tried to address with our design choices but which we can surely further improve.
Chapter 5
Conclusions and further
developments
Our simulator can be effectively used to teach how to use the Programma 101, because our design choices improve the learnability and the usability of the machine while preserving the historical accuracy of the computed results. The programming language of the original machine, although being innova-tive for the time the Programma 101 was manufactured (1965), is hard to learn and requires a lot of cognitive effort. We managed to reduce such effort by introducing an equivalent visual programming language which also has the unique feature of being a low-level block language: for this reason our laboratory can be used to introduce the assembler language to the students with prior knowledge of computer science. A field trial with a class of high school students confirmed our expectations in terms of ease of use of the simulator interface and learnability of the block programming language.
We plan to improve the simulator by implementing some missing features reported in section 2.4, such as the possibility to store constants on the mag-netic cards. We also want to further improve the usability of the machine, for example by providing more feedback about the executed instructions even when using the simulator. We will implement an interface in which the pro-grams written using the block language are translated to Programma 101 instructions and shown to facilitate users interested in learning the original language. We also plan to add the possibility to load programs from an on-line gallery: this will be useful for the users who want to see some examples of programs and will also let us introduce a new kind of exercise in which the
students need to modify or to find an error in an existing program. Finally, we will create an online repository of explanations and interactive exercises to be displayed from the website, with a mechanism to automatically check the solutions. This repository can be used as didactic material for self-study or as a support for the tutors during traditional lectures to be delivered to a wider audience.
Another feature that would enrich the simulator is the possibility to activate a ”historic mode” that hides the register values, sets the limit of 120 instruc-tions per program and performs some other acinstruc-tions that make the simulator behave exactly like the original machine. This mode can be used both by expert users and by the tutor to explain how difficult programming in the 1960s was.
Given the positive outcome and the potential of this tool, the Museum of Computing Instruments of the University of Pisa plans to include this lab in its offer of didactic laboratories available for high-school students.
Bibliography
[BGK+17] David Bau, Jeff Gray, Caitlin Kelleher, Josh Sheldon, and
Franklyn Turbak. Learnable programming: blocks and beyond.
Communications of the ACM, 60(6):72–80, 2017.
[CG13] Giovanni A Cignoni and Fabio Gadducci. Using old computers for teaching computer science. In IFIP International
Confer-ence on the History of Computing, pages 121–131. Springer,
2013.
[DASL11] Wolber David, Hal Abelson, Ellen Spertus, and Liz Looney. App inventor: Create your own android apps, 2011.
[dC16] Università di Cassino. Programma 101 simulator, 2016. URL: http://p101.unicas.it/.
[Dev20] Google Developers. Blockly, 2020. URL: https:// developers.google.com/blockly/.
[Fou07] Free Software Foundation. Gnu general public license, 2007. URL: http://www.gnu.org/licenses/gpl.html.
[Goo21] Google. Angular - introduction to the angular docs, 2021. URL: https://angular.io/docs.
[Gro21] The Web Hypertext Application Technology Working Group. Web workers living standard, 2021. URL: https://html. spec.whatwg.org/multipage/workers.html#workers. [Gua20] Massimo Guarnieri. Early italian computers: Pier giorgio
per-otto’s p101 [historical]. IEEE Industrial Electronics Magazine, 14(3):92–96, 2020.
[Mic21a] Microsoft. Makecode for micro:bit, 2021. URL: https:// makecode.microbit.org/.
[Mic21b] Microsoft. Typescript documentation, 2021. URL: https:// www.typescriptlang.org/docs/.
[ocwm19] The old calculator web museum. Olivetti programma 101 electronic calculator, 2019. URL: https://www. oldcalculatormuseum.com/c-programma101.html.
[Oli59] Olivetti. Elea 9003 Manuale Base Di Programmazione, 1959. [Oli65a] Olivetti. P101 General Reference Manual. olivetti canada
Lim-ited, 1390 Don Mills Road, Don Mills, Ontario, 1965. [Oli65b] Olivetti. P101 Manuale di Programmazione, 1965.
[Oli66] Olivetti. Olivetti programma 101 commercial, 1966. URL: https://www.youtube.com/watch?v=WnItIQSwfSw.
[PFM17] Erik Pasternak, Rachel Fenichel, and Andrew N Marshall. Tips for creating a block language with blockly. In 2017 IEEE Blocks
and Beyond Workshop (B&B), pages 21–24. IEEE, 2017.
[Pro06] NASA Johnson Space Center Oral History Project. Edited oral history transcript, 2006. URL: https://historycollection. jsc.nasa.gov/JSCHistoryPortal/history/oral_
histories/WhittleDW/WhittleDW_2-16-06.htm.
[RMMH+09] Mitchel Resnick, John Maloney, Andrés Monroy-Hernández,
Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Mill-ner, Eric Rosenbaum, Jay Silver, Brian Silverman, and Yasmin Kafai. Scratch: Programming for all. Commun. ACM, 52:60– 67, 11 2009. doi:10.1145/1592761.1592779.
[Tea20] Scratch Team. Single stepping - scratch wiki, 2020. URL: https://en.scratch-wiki.info/wiki/Single_Stepping. [WW15] David Weintrop and Uri Wilensky. To block or not to block,
that is the question: students’ perceptions of blocks-based pro-gramming. In Proceedings of the 14th international conference
on interaction design and children, pages 199–208, 2015.
[WW17] David Weintrop and Uri Wilensky. Comparing block-based and text-based programming in high school computer science class-rooms. ACM Transactions on Computing Education (TOCE), 18(1):1–25, 2017.
