Randomness in Programs

Most of the programs you have written so far probably communicated through text: a line of output in a console, a number printed, a message typed back to the user. This article introduces a different kind of program, one whose result is a picture that appears in a window. The example is called SimpleGraphicsStarter.java, which comes from Section 3.9 of the text. Its job is easy to state: it draws a large number of disks, and each disk is randomly colored and randomly positioned.

The question this article wants you to be able to answer is simple to ask and worth asking carefully: after the program has finished drawing, what does the graphics window look like? Keep that question in mind as you read. The rest of the article builds the answer step by step, starting from the idea of a graphical user interface and ending with a before and after view of the window.

The contrast with text-based programs is the key idea. A text program's result is words or numbers. A GUI program's result is something you look at: a window whose contents are the point of the program. The text introduces SimpleGraphicsStarter.java at this point because the program is small enough that the whole idea can be seen at once. It produces a graphical result, and that result is what the program is about.

Later programs in the text build on this same idea, so it is worth understanding this first example clearly before adding more complexity. When you read a GUI program, the first useful question is not how the code is written but what the window will contain when the program is done.

The defining feature of this program is that it generates graphics with random properties. The source describes the program as drawing a large number of disks, and each disk is randomly colored and randomly positioned. The word randomly applies to two properties of each disk: its color and its location in the window.

Because the properties are random, the program does not draw one fixed picture that you could predict in advance. It draws many disks, and each one has its own color and its own place. Taken together, the drawing is a collection of disks that all differ from one another. Thinking of the final picture as a collection, rather than as a single object, is the key to reading the program's result.

The figure below shows the window at two moments. Before the drawing, the window has no disks in it. After the program has drawn, the window holds a large number of disks. Each of those disks has its own color and its own position, which is what the source means by randomly colored and randomly positioned. The change from the first state to the second is the whole effect of the program.

The program's code does not change between runs, but the picture does. The randomness is what makes that possible. Each disk's color and position are chosen randomly, so two separate runs of the same program can produce disks with different colors in different places. The code is identical each time; the properties of the output are not.

The two runs share the same kind of result: a large number of disks, each with a color and a position. What differs is the specific values. This is why the useful description of the output is about its kinds of properties rather than one exact image.

This habit matters because it matches what the program actually promises. A fixed-picture description would be false on most runs. A property-based description stays true across runs, even though every run looks different.