Chapter
IIIRemote Block Execution
Data locality and network latency are important considerations when developing dis- tributed applications. Executing block functions on remote computing resources enables users to gain concrete experience with the implications of data locality and network latency.
As these computing resources may not be blocks-based programming environments, this presents a number of different research challenges. One such challenge is cross-compiling code from a flexible, lively block environment to a textual programming language. There are also semantic challenges about the appropriate block behavior in non-native environments, conforming to the concurrency model of the original environment and security considerations when compiling blocks to a textual language for execution in a new environment.
the given block’s “code” template. After defining these mappings, the user can use a block for converting a single set of scripts to code given these templates.
Figure 48: Defining a Code Mapping from Snap! to C
An example code mapping is provided in Figure 48. In this example, the user is defining the code mapping for the given for loop. The template defines the overall structure of the generated code and uses “<#N>” as a placeholder for the inputs where “N” is the index of the block’s input. In the given example, “<#1>” corresponds to the i variable, “<#2>”
corresponds to1, “<#3>” corresponds to the max of the loop (5), and “<#4>” corresponds to the body of the for loop (currently empty). Unlike many other programming languages, for is not a primitive construct in Snap! but is a custom block. Despite being a custom block, this particular code mapping does not use the block definition at all in the generated code.
After defining the code mapping, users can use these mappings to convert individual scripts using the code of block. The code of block uses the defined code mappings to generated textual representations of the given block script. An example is shown in Figure 49 demonstrating the use of the code of block to generate code for a given script. In this example, we are generating C code for a forloop which prints the iteration number on each iteration.
Figure 49: Generating Code From Blocks in Snap!
This approach to code generation certainly has its strengths and limitations. As the user can provide arbitrary code templates for any block (including custom blocks), the generated code can be quite simple and legible. Generating simple code should make the textual
# i n c l u d e < s t d i o . h > 1
int m a i n () 2
{ 3
int i ; for ( i = 1; i <= 5; i ++) 4
{ 5
p r i n t f ("% d " , i ); 6
p r i n t f ("\ n "); 7
} 8
r e t u r n ( 0 ) ; 9
} 10
Figure 50: Generated Code From Figure 49
representation appear more accessible as opposed to generation techniques which generate more complex textual code. Furthermore, as the user can define arbitrary code mappings, the target language can be very easily changed to provide users examples of how the given script may be written in a variety of different languages.
There are also a number of limitations with this approach. Users can only generate code for a single script and not an entire sprite or project. This allows the code generation to be much simpler as the generated code does not need to make any considerations with respect to concurrency. Without code generation support for multiple scripts, this approach cannot be effectively used for executing arbitrary scripts. Consequently, the execution of the generated code will likely behave differently than the original block functions (examples of such scripts are provided in Section 3.2).
Another limitation of this approach is the requirement of the user to define the custom mappings for each of the blocks that will be compiled. This significantly limits the use of this feature by novice users as custom blocks require defining a new code mapping for the given block. Requiring the user to define a new code mapping for every new custom block definition requires the user to already understand how to write the analogous behavior in the target programming language. Although this is often the case for instructors, this cannot be expected of the actual novice users. Therefore, this feature can be useful for creating examples and demos but not for actual use by novices without restricting the supported blocks they can use in their projects.
Snap4Arduino extends Snap! to support developing code to run on the Arduino [4].
Unlike the codification feature of Snap!, Snap4Arduino generates code for the entire user project without requiring the user to define templates for mapping the block to text. As Snap4Arduino is targeting the Arduino platform, it also generates the appropriate initial- ization and helper functions as well as ensures that the program contains the main loop.
The Snap4Arduino environment does not support all the features of Snap!. These include
asynchronous broadcasting, custom blocks, multi-dimensional lists and lambda expressions.
The stage, sprites, and sounds are also unsupported elements of the project when executing on Arduino.
The code generation also does not conform to the semantics of the concurrency model and will exhibit slightly different behavior during execution than Snap!. One example can be found in the approach for broadcasting events. In Snap!, the broadcast block will run a script concurrently. Specifically, the scripts responding to the event will be queued and executed after the current script completes. However, when running the same block on the Arduino, the broadcast blocks are converted into function invocations which are then evaluated synchronously. Although this is a subtle distinction, changing the execution semantics when running the code on Arduino can result in unexpected behavior and bugs that can be very difficult to troubleshoot.
3.1.2 Combined Visual and Textual Environments
After learning to program in a visual programming environment designed for educational purposes, users often want to “graduate” to a textual programming language such as Python or Java. There have been a number of studies investigating this transition as well as simply providing both options to users [137, 65, 19, 50] or providing textual language syntax on blocks [39,70]. There are a number of visual programming environments designed to address this transition [6, 41, 57, 131, 10, 9, 88]. These environments facilitate the transition from block programming to textual programming by enabling users to view the generated code from the given blocks. An example of this is provided in Figure 51.
In this example, the program will create a turtle named “Tina” and draw ten filled circles of random colors at random locations on the screen. This program is available in the block environment on the left and also shown as code in the right pane. Selecting a block will also highlight the corresponding code that has been generated for it on the right. In Figure 51, the block which sets the turtle’s speed is currently selected and the corresponding python code (“turtle.speed(10)”) is highlighted on the right. This makes the transition easier by allowing users to view their projects in python as well as easily determine the relationship between the individual blocks in their program and the individual lines of code in the generated python program.
Figure 51: Editing Blocks and Text Together in Trinket