Blue

Blue is a small, pure object-oriented programming language and integrated development environment built for one job: teaching object-oriented programming to first-year university students. Michael Kölling and John Rosenberg designed it in the mid-1990s at the University of Sydney’s Basser Department of Computer Science, and development later moved to Monash University in Melbourne. Blue was first presented at the SIGCSE Technical Symposium in 1996, and Sydney used it in its introductory course from 1997. Few people remember the language itself. Its environment is better known, because it became BlueJ, which kept Blue’s interactive, diagram-centred design and put Java in place of the Blue language.

History & Origins

The problem: no good first object-oriented language

By the early 1990s many computer science departments wanted to teach object orientation from the very first course. The languages on offer had been designed for professionals. In their March 1995 SIGCSE paper, “Requirements for a First Year Object-Oriented Teaching Language”, Kölling, Bett Koch and Rosenberg looked at C++, Smalltalk, Eiffel and Sather and concluded that none of them suited beginners. The paper ended by sketching the characteristics of a new language designed for teaching.

Kölling was working on his PhD at Sydney under Rosenberg. In the acknowledgements of his thesis, dated September 1998, he says the project had “started four years ago”. The first two papers describing Blue by name appeared at the 27th SIGCSE Technical Symposium in Philadelphia, published in the March 1996 SIGCSE Bulletin:

• “Blue — A Language for Teaching Object-Oriented Programming” (pp. 190–194), which described the language as “currently under development explicitly for object-oriented teaching”
• “An Object-Oriented Program Development Environment for the First Programming Course” (pp. 83–87), which argued that for beginners the environment may matter more than the language

Into the classroom

The Basser Department took what Kölling called “the brave step” of adopting Blue for its first-year course in 1997. Students used it for two semesters and then moved on to C++. According to the thesis, the first semester went “unexpectedly smoothly”. In the second semester students wrote more complex programs, especially ones combining circular class dependencies with generics, and found more bugs. The system became reliable by the middle of the first semester of 1998. For Blue’s second year in use, Sydney staff (Jeff Kingston, Alan Fekete, Tony Greening, Judy Kay and Nicole Lesley) wrote an introductory textbook based on Blue.

In November 1997 Kölling and Rosenberg published the full language definition, “Blue — Language Specification, Version 1.0”, as a Monash technical report (TR97-13). By then the project’s web pages had moved to Monash’s Department of Software Development, where Rosenberg had become Dean of the Faculty of Computing and Information Technology and Kölling had taken a lecturing post.

Succeeded by BlueJ

The thesis, completed in 1998 and awarded in 1999, already describes the next step: “We have started to develop a Blue-like system for Java. The Blue language was replaced with Java as the supported language, while the environment remains to a large extent unchanged.” That system was BlueJ. Its version 1.0, “the first full official BlueJ release”, was announced on 23 August 1999. After that, development effort went to BlueJ, and Blue was not developed further.

Design Philosophy

Kölling’s 1999 JOOP column “The Blue Language” opens by anticipating the reader’s reaction (“Oh no – not another language!”) and then states the case for Blue:

“The significant difference that distinguishes Blue from other languages is that it is an object-oriented language specifically developed for teaching. Pascal was such a language for procedural programming… Other existing object-oriented languages try to serve different customers simultaneously… With Blue, we do not try to serve both ends.”

Several principles follow from that position:

• Pure object orientation. All code lives inside classes. There are no free functions and no main outside a class, so students cannot write procedural programs in an object-oriented language.
• Small enough to learn completely. Kölling argued that students should reach the point of knowing every construct in the language during their first year, which “was possible when we were teaching Pascal or Lisp”.
• No redundancy. If two constructs do the same job, one is removed. Blue has one parameter-passing mode, one loop statement and one way to create objects.
• Readability over brevity. The syntax uses keywords “in the Algol/Pascal tradition”. Kölling wrote that it “looks like a relative of Eiffel, although there are many differences in numerous details.”
• Stepping stone, not a destination. The designers “tried to resist the temptation to invent revolutionary new constructs”. They chose mainstream mechanisms so that the skills would carry over to C++, Java and other languages.
• Efficiency is expendable. Teaching needs are placed above runtime performance, which is why Blue can afford extra runtime checking.

Key Features

A rigidly structured class

Every Blue class has its parts in a fixed order: header, a compulsory class comment, a uses list, an internal section (private variables and routines), an interface section (creation routine and public routines), and an optional class invariant. Variables cannot appear in the interface at all. This example is from Kölling’s thesis:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

class Stack <ELEM_TYPE> is
=============================================================
== Author: M. Kölling / Jeffrey H. Kingston
== Version: 1.1
== Short: Stack of ELEM_TYPE with variable size
=============================================================
uses
internal
  var
    elements: Array <ELEM_TYPE>
    numElements: Integer
interface
  creation is
  == create a new, empty Stack; O(1) cost
  do
    elements := create Array <ELEM_TYPE> (20)
    numElements := 0
  post
    isEmpty
  end creation

  routines
  push (elem: ELEM_TYPE) is
  == push elem; O(1) cost plus resizing cost
  do
    if numElements = elements.size then
      elements.setSize (2*numElements)
    end if
    numElements := numElements + 1
    elements.putElem (numElements, elem)
  post
    not isEmpty
  end push

  pop -> (elem: ELEM_TYPE) is
  == pop elem; O(1) cost
  pre
    not isEmpty
  do
    elem := elements.getElem (numElements)
    numElements := numElements - 1
  end pop

  isEmpty -> (empty: Boolean) is
  == true if empty; O(1) cost
  do
    empty := (numElements = 0)
  end isEmpty
invariant
  numElements >= 0
end class

(Indentation added for readability; the thesis figure is flush-left in the extracted text.)

The example shows most of the language: generic classes, pre/post conditions and class invariants, which the runtime system checks, named result variables, and the rule that a routine’s name is repeated at its end.

Two kinds of compulsory comment

The compiler reports an error if a class or a routine has no comment. Blue has two comment forms:

From version 0.8.28 (May 1997) interface comments could also be used inside pre- and postconditions, so that conditions that cannot be written as code can be stated in plain English.

Multiple results instead of out parameters

All parameters are passed by value. Because every variable holds a reference, objects themselves are effectively shared. A routine returns information through a separate result list, and callers receive it with a multi-assignment:

1
2
3
4
5
6
7
8

findElem (index: Integer) -> (found: Boolean, elem: Element) is
== Return element at 'index'. If it exists, 'found' is true
== and 'elem' is the element. If not, 'found' is false and
== 'elem' is nil.
...

success, element := findElem (2)
a, b := b, a          -- swap

The compiler requires every result variable to be assigned somewhere in the routine body, and the runtime reports an error if any are still undefined when the routine returns. Kölling compared this with Ada 95’s in/out/in out modes and argued that Blue makes it obvious at the call site which variables change.

Everything is a reference, and “manifest classes”

Blue has no stack-allocated “immediate” objects. Every variable holds a reference, assignment copies references, and the default equality test compares identity. To make integers and booleans objects without requiring create 7, Blue divides classes into two kinds:

• Constructor classes: ordinary classes whose instances are made with create
• Manifest classes: classes whose instances all exist from system start-up and are referred to by name. Integer and Boolean are manifest, so 3 and true are constant references to existing objects.

The same mechanism gives Blue object-oriented enumerations, which Eiffel and Java lacked at the time:

1
2
3
4

class Colours is Enumeration
== some sample colours
manifest red, green, blue, yellow, purple
end class

Undefined-variable detection

A variable can be declared without an initial value, but then it is undefined rather than silently zero or nil. Using an undefined variable causes a runtime error. Kölling argued that automatic default initialisation is the worst option for teaching, because a legal but wrong default value hides the student’s mistake. He noted that CLU’s definition specified similar checking but that it “was never implemented in the compiler”.

One loop

Blue has a single loop … end loop construct with any number of exit on conditions. It covers the cases handled by while, repeat and for:

1
2
3
4
5
6

col := red
loop
  exit on col = nil
  process (col)
  col := col.succ
end loop

Aliases: familiar syntax over a uniform model

The pure model says addition is m.add (n), but beginners expect m + n. Blue therefore provides a small, fixed set of aliases, shorthands that the language defines in terms of the underlying object operations. m + n stands for m.add (n). print ("The answer is: ", n) stands for terminal.write (str ("The answer is: ", n)), and str in turn expands to chained toString/concat calls. Users cannot define aliases of their own. The idea is that teachers present the familiar forms first and explain what they stand for once students understand message passing.

Deliberately limited inheritance

Blue supports single inheritance only. Inherited routines cannot be renamed or hidden, and parameter types cannot change in subclasses: Blue has neither Eiffel’s covariance nor Sather’s contravariance. The aim was to teach inheritance as a clear “is-a” relationship and leave inheritance purely for code reuse to a second course in another language.

Genericity from the start

Blue supports constrained and unconstrained generic classes. At the time Java had no generics and C++ templates were still immature, and Kölling wanted students to use proper collection classes such as lists early on instead of falling back on arrays because lists seemed hard to teach. Array is predefined, because it is the only collection that cannot be written in Blue itself.

The Blue Environment

The language and environment were designed together, and several features of the environment later became characteristic of BlueJ:

• A project window showing classes as boxes with inheritance and “uses” arrows. Students begin by reading and modifying an existing project rather than writing an empty main
• Interactive object creation: students create an instance straight from the class diagram, call its interface routines with dialog boxes, and inspect its state, all without writing a test driver
• An integrated editor, Red, which generates class skeletons with placeholder comments and keywords already filled in (Red was also released as a stand-alone text editor)
• A class/library browser, a debugger, a “Notebook” and a “ChangeLog” (added in version 0.8.25, May 1997)
• A generated interface view of each class, built from the == comments and pre/postconditions

Implementation

According to Chapter 8 of Kölling’s thesis:

• Blue was written in C++ (g++), with X Windows and Motif. It was developed on Solaris 2.5 and later ported to Linux. A Microsoft Windows port was “almost complete” in 1998 but was not yet fit to distribute, and no native Windows release appears on the project’s archived download pages.
• The source was about 85,000 lines, written in a strict object-oriented C++ style.
• The compiler is a recursive-descent LL(2) parser generated with ANTLR. ANTLR was chosen over LR generators because recursive descent gives better control over error messages.
• Compiled code runs on a custom abstract machine, a simple register/stack machine with eight registers, a heap and a mark-and-sweep garbage collector. The pipeline goes from .blu source through .aml assembly and .sym symbol files to .amc code files.
• The user interface and the virtual machine run in separate threads, so a student can stop a runaway loop from the GUI.
• Kölling implemented the environment, and a department programmer named Bignucolo wrote the compiler. The thesis gives his first name as Oscar in one place and John in another. Stefanie Fetzer worked on the abstract machine, Jeff Kingston wrote the collection library, and Axel Schmolitzky designed the GUI library.

Resource use in the Sydney deployment

The thesis gives one real-world measurement. On the Sydney teaching server (a dual-processor Sun Ultra running Solaris 2.5, with about 120 X-terminals and roughly 60 running Blue at a time), the first Blue process used about 1.2 MB of main memory and each additional concurrent copy about 150 KB more, because most of the code was in shared libraries. Kölling reported that 60 concurrent copies were “comfortably supported” by that hardware. No speed benchmarks against other systems were published.

Evolution

The project’s archived version history shows rapid releases during 1997, the first teaching year:

A GUI library and an improved multi-library browser were being built when the thesis was written. The thesis says the language definition itself “is stable and will not be changed in the near future.”

Current Relevance

Blue is a historical language. Its Monash web pages were gone by late 2000 (the csse.monash.edu.au/blue address returned 404 Not Found in October 2000), and no maintained distribution or Docker image exists. The language specification, the thesis and the 1999 JOOP columns are still available, including through the University of Kent’s KAR repository, so the design is well documented even though the software is hard to obtain.

Blue’s ideas are still in use through BlueJ, which followed Kölling from Monash through posts at the University of Southern Denmark and the University of Kent to King’s College London. BlueJ became free and open-source software in March 2009 and is still maintained. Kölling later designed the Greenfoot environment and the Stride frame-based language, but the sources consulted here do not describe Stride as derived from Blue.

Why It Matters

Blue took the position that a teaching language should be designed for teaching and nothing else, as Pascal had been for structured programming, rather than being an industrial language used in a restricted way. Several of its choices are now common in education and in mainstream languages: enforced documentation comments, preconditions and postconditions checked at run time, errors for undefined variables instead of silent defaults, and treating all values uniformly as objects.

Its most lasting contribution was the environment. Creating objects directly from a class diagram, calling their methods interactively and inspecting their state, without writing a main method, came from Blue. That idea reached many students through BlueJ. At SIGCSE 2010, when panellists named the most influential computing-education papers, Kölling and Rosenberg’s 1996 paper on the Blue environment was on the list.