Da Vinci Code

With graphical development environments, programmers simply use a mouse to draw a flowchart; then, the development environment translates it into a finished application. Developers do not need to learn cryptic commands, and they neither produce syntax errors nor suffer buffer overflows. Ideally, the development environment will even step through the program, visually emphasizing the currently active component and dramatically facilitating the troubleshooting process.

The first graphical development environments emerged in the 1960s, but only GUI editors or Rapid Development (RAD) tools are in common use. Developers use them to click together user interfaces for their applications (e.g., Glade [1] and Qt Designer [2]); however, in reality, only laboriously typed chunks of code bring the GUI elements to life. Design tools are similarly restricted, especially tools for Unified Modeling Language [3]. Again, they generate a code framework that the programmer fills with content at the keyboard.

If you look hard, you will find a surprisingly large number of visual programming languages (VPLs), for which their inventors usually include a suitable development environment. Often, the development environment is designed with a specific field of application in mind.

Etoys and Co.

Etoys [4] is a development environment designed to help children do tasks such as write interactive stories in the classroom or program the orbits of planets. In this way, Etoys seeks both to make programming palatable to students and to give them a fun way to learn math while explaining science intuitively and helping improve language skills.

The software was created by Apple in 1996 as Squeak and soon moved to Disney Imagineering Research and became Etoys. It then went to Viewpoints Research, who created the Squeakland Foundation now currently working on expanding Etoys. The open source project is supported financially by several entities, including Intel and HP. Sugar OS, the operating system for the hardware used by the one laptop per child (OLPC) project, also includes Etoys.

If you fail to find the development environment in your distribution's repository, you can pick up a version from the project homepage, but only for 32-bit systems. Just extract the corresponding ZIP archive and then run etoys.sh. Some parts of Etoys are subject to the MIT and Apache licenses.

After starting a new project, the developer first draws small two-dimensional objects, such as cars, roads, or houses, with the built-in drawing tools then arranges then on a white canvas to create a small scene. If you right-click an object, icons appear as a "halo" around the object (Figure 1) that you can use to rotate and resize the object and open the Viewer (the eye icon). A palette of functions opens related to the object, which you can then drag and drop to compile a script. If a function requires parameters, such as the number of degrees for rotation, you just set it by clicking. Alternatively, you can create variables.

Figure 1: The script shown here drives the small red car across the screen. The star can be manipulated via the icons shown on-screen.

Etoys even has rudimentary version management. The development environment is based on the Smalltalk Squeak implementation, but the object-oriented underpinnings are hidden from the user; Etoys only reveals the corresponding Smalltalk source code on request.

The developers provide extensive documentation in the form of a PDF file and a wiki on the website. Even with numerous examples and free instructional videos (screencasts), the learning curve can be fairly steep, and using Etoys is fiddly and unintuitive.

Related alternatives for smaller children are Scratch [5] or Snap [6]. Both provide functions in the form of candy-colored blocks (Figure 2). The insertion and nesting notches make it easy to fit a program together, and color-coding helps highlight the individual code components (e.g., loops are dark yellow).

Figure 2: Snap programs (called scripts) are composed of multicolored blocks.

Scratch v2.0 and Snap, however, are designed as web services: Snap can be launched only via its homepage, and the offline version of Scratch v2.0 requires the Adobe Air run-time environment, which is very difficult to run on Linux. Scratch version 1.4, though, is available as a fully functional desktop program.

The Alice [7] development environment is targeted more at teachers who want to interest their students in 3D programming (Figure 3). The focus here is more on object orientation. The current version 3.1 is based on Java and unusually uses a wizard for the install. The wizard downloads almost 1.2GB of data from the Internet, including 3D objects such as people and household objects from The Sims 2 computer game. (Alice programmers can only use these objects for non-commercial or academic purposes, however.) Alice is released under its own license [8], which allows free use.

Figure 3: Young Alice developers can make a 3D character (e.g., a wolf) run through a scene.

As with Etoys, the finished flowcharts are very similar to simple, imperative programs, with a box painted around each statement. On request, Alice shows the Java code; in this case, the functions in the flow chart have the parameter list in parentheses. This view is useful if you want Alice to provide Java programming support for beginners. The built-in screen capture function records completed animations; as a bonus, you have a direct link to YouTube. The Alice homepage has a variety of tutorials and examples, and even sample teaching materials.

Blockly

At first glance, Blockly [9], developed by Google and released under the Apache license, looks similar to Snap or Scratch. However, you can integrate the visual code editor into your own web applications to help the users of your web app create macros, for example. Blockly is thus more of a framework, and the supplied code editor just an example of a Blockly application.

In all Blockly applications, the developer uses the building blocks from the palette on the left to put together the program on the right. The different control structures use different colors (e.g., loops are green). You can group multiple statements into functions and create variables. That said, Blockly only creates imperative programs.

With the help of the visual programming language, programmers can both put together their programs and translate them automatically into Python, DART, and JavaScript code or convert them to XML in the background. The editor displays the generated code directly in the corresponding tabs (Figure 4).

Figure 4: Blockly code translated to other languages.

By default, Blockly only understands a few blocks with important basic functions. Coders use a separate editor, known as the Block Factory to create their own modules. On the left side, the developer sets the appearance of the block, whereas the text editor on the right is for handling the logic. But you need to write this in normal JavaScript.

Documentation for Blockly is quite rudimentary and limited to a wiki. Samples supplied by users give you further clues. For example, they show you how to integrate Blockly into your own web application (Figure 5). After checking out the current Blockly source code from the Subversion repository, you will find the examples in the subdirectories under blockly/apps/.

Figure 5: A function created as a graph from the Blockly blocks on the right.

Drakon

The Drakon homepage [10] gives you the impression that you can draw your application in the form of a flowchart, and then the Drakon editor exports the finished plan as source code in Java, C, C++, Python, and many other languages. However, Drakon is merely a visual specification language that lets developers sketch their program flows. Designed by employees of the Russian space program, it was intended to help in the design of missile control systems.

To help you draw the diagrams, the makers provide the Drakon editor, which also generates the source code. However, this only works if the editor finds the appropriate instructions in the desired programming language in the diagram elements (Figure 6).

Figure 6: The Drakon editor only generates source code if the developer has deposited the relevant instructions in the elements of the diagram.

Drakon therefore is not strictly a graphical programming language, and the editor is extremely cumbersome to operate. Developed in Tcl/Tk, this utility does not support a snap function: If you move an item, you thus need to connect all the lines manually. Documentation is available for Drakon only; users are forced to explore the editor on their own, but at least it is public domain.