As a college student learning to program, I had a strong independent streak. I wanted to do everything “from scratch” - no libraries, no frameworks, just me and the code. Only later did it occur to me to ask what a programming language was, how it worked and - the question that most threatened my self-sufficiency - who had made them.

The words “map”, “filter” and (brace yourself!) “reduce” have a strange mystique among programmers. But they’re worth getting to know. In many languages, these techniques offer a concise and straightforward syntax for common data transformations. The purpose of this post is to demystify map, filter and reduce with some simple visual examples.

For the past couple weeks, I’ve been playing my way toward a tool that converts pencil sketches to clean line art. The tool remains forthcoming. But here are a few of my most visually pleasing mess-ups along the way:

Who do we “speak” to when we code? Beginner programmers often hear that code is “instructions to the computer.” But as we take on larger projects with more collaborators, we learn to use code to communicate with humans, too - with our future selves, with potential employers, with coworkers. We use our code to document our thinking, but also to impress, instruct and even amuse.

A large variety of systems - biological, sociological, technological - can be represented as graphs: nodes representing entities, with connecting edges representing interactions between them. To understand the structure of a network, we may want to detect communities - clusters of nodes that are densely connected to each other. Algorithms such as the Louvain method of community detection involve iteratively re-assigning the nodes to communities, while attempting to optimize the quality of each partition. That is, at each step, the algorithm asks, “How good is this split? How well does it capture the structure of the network?” This measure is called modularity.