Archives for : languages

Public static void main: because you’re worth it

I’ve been thinking a bit about the “magic” phrases we find in some programming languages. But then last night, I watched an episode of the BBC’s Outnumbered, where Karen conducts (her take on) a funeral service for a mouse:

…dust to dust,
for richer or for poorer,
in sickness or in health,
may the force be with you,
because you’re worth it.
Amen and out.

The bane of many a Java beginner’s life might be the (slightly less poetic),

public static void main(String args[])

It’s unfair of me to pick on Java specifically, but that’s just an easy example to use. If we repeat that kind of phrase, verbatim, in every one of our first few programs, at which point does it become recitation? It’s like a sort of solemn vow reminding us we’re starting a Java program – a programming ritual. Like various ceremonies, it’s evolved over time, from “int main (void)”, in this case.
Of course, these sorts of things used to be done in Latin, for all that extra weight. Google Translate has alpha support, and suggests “Primor incorporalis sine publico (catena args)”. The thing is, is this actually that less meaningful to, say, a 12 year old?
So, repeat after me:

…for richer, for poorer,
in debugging and at runtime,
primor incorporalis sine publico.
Live long and prosper.*

A new language for beginners?

A summary of my PhD proposal has been placed on my research page at the University of Kent:

* * *

This PhD project concerns the design of a new type of programming language for teaching, one that tries to combine the benefits of textual input with those of a structured and flexible graphical code output.
Recently, the three most prominent programming tools for beginners are Scratch, Alice and Greenfoot (discussed in Utting et al. 2010). Both Scratch and Alice are visual blocks-based languages. Greenfoot’s code view is less graphics-rich, resembling more of a traditional code editor. In coding terms, there is still a large “jump” for students from visual tools to more traditional code editors, even in teaching systems.

Visual programming tools do some things very well; they can remove completely the possibility of syntax errors (Maloney et al. 2010). The tool palettes of block languages allow students to work under recognition rather than recall, in interaction terms; it is not necessary to remember all of the commands or structures, since prompts are provided. Unfortunately, these visual languages can also be restrictive. The palette means that there are only a very specific number of available code blocks. Speed of writing is also an issue. Scratch is aimed at users from 8 to 16 (Maloney et al. 2010). It uses the mouse almost exclusively; after the initial learning period, dragging and dropping blocks with the mouse might become quite tedious, especially when writing long programs. Students aged 15 or 16 might reasonably be expected to be proficient enough on the keyboard to find “pure” mouse interaction slow and time-consuming, compared to the speed at which they can type.

This project suggests looking for another option, where text-based input and graphics-based output can be combined. Greenfoot and the Karel-family (starting with Pattis 1981) have graphical output of the program execution. Their code editors, however, are text-based, and that is what is being examined here. Informally, programming editors (not the model) can be sketched on a graph (Figure 1*) of two axes: the balance of mouse and keyboard input, and the corresponding balance from textual to graphical output. Most tools are found at opposite corners of the graph, with little overlap between text-based and graphics-based languages.

Figure 1: Input and output paradigms

The proposal here is for a tool that fits somewhere in the upper-left quadrant of that graph, where we have the speed and flexibility of text input, but the student benefits from the editor visualising the structure of the code to a similar extent as is done with block-based programming, not necessarily in the same way.

* Acknowledgement: Michael Kölling

References:

  • Maloney, J., Resnick, M., Rusk, N., Silverman, B. & Eastmond, E. 2010, “The Scratch Programming Language and Environment”,  ACM Transactions on Computing Education (TOCE), vol. 10, no. 4, p. 16.
  • Pattis, R.E. 1981, Karel the robot: a gentle introduction to the art of programming, 1st edn, John Wiley & Sons, New York, USA.
  • Utting, I., Cooper, S., Kölling, M., Maloney, J. & Resnick, M. 2010, “Alice, Greenfoot, and Scratch–A Discussion”, ACM Transactions on Computing Education (TOCE), vol. 10, no. 4, p. 17.