Part of a series of posts explaining programming for the lay-person.
This is part of a series of posts; see the introduction to this series. This entry overviews named and unnamed blocks, which are ways of grouping statements.
Blocks are very simple. You take two or more statements, string them one after the other, and call that collection a single statement. Most commonly they appear unnamed within control constructs, as in “if it is raining, bring an umbrella and walk quickly”, where “bring an umbrella and walk quickly” is a block; or (from two posts ago):
Why even bother having a name for this trivial idea?
Mostly because it makes formalizing things easier for the language designers.
They can say simply
“a while loop has the form
while (guard) statement”
The guard here is typically defined as
an expression with type “boolean”,
meaning its value is either “true” or “false”.
and let the definition of blocks as a kind of statement
handle how to get more then one action into the loop.
Why bring them up? Because there is no real parallel to blocks in English. We can speak lists; with some effort we can even speak list of lists; but it gets messy when we try to nest things too deeply. Even simple phrases like “if it is raining, bring an umbrella and walk quickly” might mean that we are to walk quickly whether or not it is raining. Thinking in blocks is simple, but it is nonetheless new.
Subroutines are also called methods, functions, and procedures. While each of these four terms has a slightly different denotation, they are similar enough they often get used interchangeably. The subroutine is a very powerful idea in programming. The idea, again, is superficially simple: we name a block, then use that name elsewhere in the program. Recipe books often do this: they describe how to make frosting once and then simply state “make the frosting” everywhere it is needed. Subroutines show all over the place: “The game consists of a play phase and a scoring phase. The play phase proceeds in rounds. Each round, …”. Naming groups of ideas is how language makes sense of complexity.
In programming, we speak of defining a subroutine when we describe what we mean by the name. Referring to the name elsewhere is called calling, executing, invoking, or running the subroutine, with all four phrases used pretty freely.
Subroutines can be a little more complicated than simply a name. Most subroutines in programming have parameters. This idea is familiar from mathematics: in “the sum of x and y” x and y are parameters or arguments Again, “parameter” and “argument” are not technically synonyms, but the difference between them is small enough people often use them interchangeably. of the subroutine “sum”. We also use these in English; for example “drive to the grocery store” invokes the subroutine “drive to” with the argument “the grocery store”.
The examples “sum” and “drive to” also highlight that some subroutines are expressions while others are statements. In other words, “the sum of 3 and 5” is a noun phrase describing a thing, 8; Thanks to Markham for correcting my arithmetic here… on the other hand “drive to Tennessee” is an instruction and doesn’t describe anything. In programming parlance, we say that subroutines that are expressions return a value, while other subroutines are sometimes described as being void.
There are a lot of other interesting features of subroutines; we’ll come back to them often in the future.
In parting, let me present a general idea of how these might be used.
Looking for comments…