Naming as Abstraction: SICP's Lessons on Software Design

The article opens with Phil Karlton's famous observation that naming is one of the two hardest problems in computer science, then draws heavily on Structure and Interpretation of Computer Programs (SICP) to argue that naming is not merely labeling but the core mental process for controlling complexity, building abstractions, and creating a working vocabulary for software design.

One thing the human mind seems to do well is to name things; we have powerful associative memories. Given a name, we can quickly recall some associated thing to mind.

This associative power underpins modularization: instead of feeding raw descriptions to a universal function, we give names to pieces and refer to them by name.

So while in principle we could get by with just one universal function, we prefer to modularize our code, to give names to the various pieces, and to mention the names of function descriptions rather than constantly feeding the descriptions themselves to the universal function.

Building a vocabulary through naming enriches the language in which we write programs.

In my 1998 talk “Growing a Language,” I commented that a good programmer “does not just write programs. A good programmer builds a working vocabulary.” As we design and define more and more parts of our programs, we give names to those parts, and the result is that we have a richer language in which to write the rest.

Naming also applies to data structures, allowing us to draw distinctions and manipulate them as units.

But we also find it natural to draw distinctions among data structures, and to give them names.

SICP emphasizes that names are chosen deliberately to enhance understanding of program structure.

As you read this book, please pay attention not only to the programming language constructs and how they are used, but also to the names given to functions and variables and data structures. They are ... chosen in a deliberate and systematic way to enhance your understanding of the overall program structure.

Any powerful language provides three mechanisms: primitive expressions, means of combination, and means of abstraction — the last allowing compound elements to be named and manipulated as units.

Every powerful language has three mechanisms for accomplishing this: primitive expressions... means of combination... and means of abstraction, by which compound elements can be named and manipulated as units.

Constant declaration is the simplest abstraction, letting a simple name refer to a compound operation's result.

Constant declaration is our language’s simplest means of abstraction, for it allows us to use simple names to refer to the results of compound operations...

The interpreter must maintain an environment — a memory of name-object pairs — to associate values with names and retrieve them later.

It should be clear that the possibility of associating values with names and later retrieving them means that the interpreter must maintain some sort of memory that keeps track of the name-object pairs. This memory is called the environment...

Numerals name numbers; names denote objects in the environment.

The values of numerals are the numbers that they name, and the values of names are the objects associated with those names in the environment.

The environment determines the meaning of names in expressions; without an environment, an expression like x + 1 has no definite value.

The key point to notice is the role of the environment in determining the meaning of the names in expressions. In an interactive language such as JavaScript, it is meaningless to speak of the value of an expression such as x + 1 without specifying any information about the environment that would provide a meaning for the name x.

Local names act like pronouns in natural language.

The thing to be multiplied is given a local name, x, which plays the same role that a pronoun plays in natural language.

Function creation and naming are separate operations; anonymous functions and naming existing functions are both important.

Observe that there are two different operations being combined here: we are creating the function, and we are giving it the name square. It is possible, indeed important, to be able to separate these two notions—to create functions without naming them, and to give names to functions that have already been created.

A function's name is a symbol associated with its definition in the environment; parameters are names used inside the function body to refer to arguments.

The name is a symbol to be associated with the function definition in the environment. The parameters are the names used within the body of the function to refer to the corresponding arguments of the function.

Parameter names are bound variables; the function's meaning must be independent of the specific parameter names chosen — a principle with profound consequences.

One detail of a function’s implementation that should not matter to the user of the function is the implementer’s choice of names for the function’s parameters. ... This principle—that the meaning of a function should be independent of the parameter names used by its author—seems on the surface to be self-evident, but its consequences are profound.

A parameter's name is bound by the function declaration; the scope of a name is the set of statements where the binding is effective.

A parameter of a function has a very special role in the function declaration, in that it doesn’t matter what name the parameter has. Such a name is called bound, and we say that the function declaration binds its parameters. ... The set of statements for which a binding declares a name is called the scope of that name.

First-class elements can be referred to by name; JavaScript grants functions full first-class status.

Some of the “rights and privileges” of first-class elements are: * They may be referred to using names. ... JavaScript, like other high-level programming languages, awards functions full first-class status.

Pairs are data objects that can be named and manipulated like primitives.

Notice that a pair is a data object that can be given a name and manipulated, just like a primitive data object.

Modeling state variables with symbolic names requires an assignment operation to change the value associated with a name.

In particular, if we wish to model state variables by ordinary symbolic names in the programming language, then the language must provide an assignment operation to enable us to change the value associated with a name.

When a single computational object is accessed by multiple names, the phenomenon is called aliasing.

The phenomenon of a single computational object being accessed by more than one name is known as aliasing.

An environment is a sequence of frames, each a table of bindings associating names with values.

An environment is a sequence of frames. Each frame is a table (possibly empty) of bindings, which associate names with their corresponding values.

Expressions have no intrinsic meaning; they acquire meaning only relative to an evaluation environment.

Indeed, one could say that expressions in a programming language do not, in themselves, have any meaning. Rather, an expression acquires a meaning only with respect to some environment in which it is evaluated.

The article concludes that naming is magic: it hides underlying details and creates higher-order concepts in the language.

Naming is not just labeling; it is the magic that hides underlying details and creates higher-order concepts in the language.