Introduction to Programming

Our original definition of programming [ref], mentions that the instructions we create while programming describe what a system should do or how it should behave.

The difference between the two is very subtle.

Consider a cookie recipe:

Each of the above steps assumes the reader knows how to perform each of the actions (mix, scoop, etc.).

Notice how each “how” step could be treated as a “what”, and broken down further:

We could keep going deeper and deeper…​

In practice, we stop at some point; where we stop depends on what level of instructions we expect the “system” that is processing the instructions to understand.

For our cookie recipe, if you are writing it for a friend who has baked before, (1) is probably sufficient, but for someone who has never stepped inside a kitchen, you may need to go a level or two deeper. If you’re trying to create a cookie making robot, you’d need to get down to the level of “emit a 5V signal on this wire for 0.5s” (to turn on a motor, to move the arm, to pick up the spoon…​)

Also notice that the language that is used varies; an experienced cook probably knows what “braising” means, but a beginner would need that explained; a pianist knows what “allegro” means, but most people don’t; these domain-specific terms are used to save time. When you need to explain something, you adapt your language based on what your audience understand. It’s the same with programming - a programmer needs to adapt their language to what the processor (be it a computer or an aspiring chef) can understand.

“levels of abstraction”

We’ve already made a few important observations about programming:

The last observation is especially important. To program a system, you must know what a system can do and what instructions it understands. Most of programming is learning about various systems that can be programming and then applying that knowledge to make those systems do what you want.

There are hundreds of different kinds of “computers” (desktops, laptops, tablets, phones, watches, cars, refrigerators), and each is composed of hundreds of interoperating systems. (ref appendix: down the computer rabbit hole) Fortunately, much of what programming entails is transferable between different programmable systems.

In this book, you’ll be learning the basics of “how to program”, or perhaps more accurately, to learn to “think like a programmer”.

What you will be programming, and the language you’ll be programming in doesn’t really matter. But…​ in order to teach you how to program (in general), this book will also teach you how to program web applications with a real, practical programming language: Clojure [ref: . Why Clojure].

But before we start learning Clojure proper, let’s make a few more observations about systems and instructions using a simple made-up system.

We write programs to solve a certain problem using a certain system. The system we choose contrains us in the way we can program it, and the problem we choose constrains in the way we solve it.

Our program is the mediator between these two domains (the “problem” domain and the “solution” domain) and will often be made of many layers (of abstraction, as we had learned in the previous chapter).

Here is a Pacman-bot system:

Let’s take the role of designers of this system. As the designers, we want to provide other people the ability to program Pacman-bot to move around the board (presumably to get the Cherry and avoid the Ghosts, but who knows what people will come up with). How might we allow people to program Pacman-bot?

Here are a few possible sets:

What we’ve come up with are programming languages! They are very limited, but, yes, they are programming languages. (Now you can tell your friends that not only can you program, but you’ve designed a programming language!)

(Also worth noting: all the examples above are text-based instruction languages, but you could also have come up with visual instruction systems (drawing a map, using colors, using pictograms), a sound-based system, a hand gesture system…​ anything)

A few things to notice:

Later in this book we will be learning about the Clojure language and all the instructions it supports and how we can combine them to solve problems.

Before we move on from pacman-bot, let’s try the following: can we convert between the different pacman-bot languages? If someone gave us pacman-bot that only understood Language X (v>^<) could we still program pacman-bot to understand a Language Y program (n5e3w1)? If v>^< are the only instructions that Language X allows, then the answer is “no”, at least not directly, but we could write another system that could convert from Language Y to Language X. It might look something like this:

Can you see how the rules above would allow us to convert from n5e3w1 to ^^^^^>>><?

Now how about converting from Language Z (goto! x y) to Language Y v>^>? Ponder that for a moment.

Hmmm…​

We have a problem. In order to make pacman-bot follow the (goto! 3 1) instruction using the v>^< instructions, we need to know where pacman-bot is before we give him the command. Before, with Language X, we were able to blindly convert from one language to another, but this time, we need some information first (pacman-bot’s starting location).

In our pacmanbot-system, pacmanbot’s location is at (x,y) = (3,4).

Lets refer to pacman bot’s starting location as pacmanX and pacmanY (so, for figure1 we would say that pacmanX is 3 and pacmanY is 4).

Now, back to our problem: how do we go from an instruction like (goto! 3 1) to v>^< style instructions? (knowing that pacman-bot starts at pacmanX and pacmanY)

One way we could write down the rules could be:

Our goto! command depends on pacman-bot’s initial position (pacmanX and pacmanY), which we could also say is pacman-bots “initial state”. The command also needs to be given the targetX and targetY, which are pacman-bot’s final target position (or “end state”). We can think of our goto! command as “taking pacman-bot from some initial state to some target state.”

What if we wanted to implement Language Z now (find! object)?

First off…​ we need some extra information. Whereas before, we were given the location to go to as part of the instructions, ex. (goto! 3 1), now we will be given an object, either the cherry or the ghost, so we will need to know their locations. Lets call the cherry’s location cherryX and cherryY, and the ghost’s location ghostX and ghostY.

We could implement the (find! object) command as follows:

Our instructions here are very similar to what we had before with (goto! x y). They’re also very repetitive.

What if we could just use (goto! x y) inside of our (find! object) command? What might that look like?

Here’s what we might end up with:

Bam! That’s all we need. Ponder it for a moment.

What we’ve done is pretty impressive. We’ve written rules so we can convert from (find! object) to (goto! x y) to v>^< style instructions.

Another way to think about it, is that we’ve written instructions at “different levels of abstractions” (from chapter 1, remember?)

Later, we’ll learn that the find! and goto! commands we defined would typically be called “functions”. v, >, ^ and < could also be called “functions”, except in our examples, v>^< were provided to us by the pacman-bot system, while find! and goto! we created ourselves.

Defining “functions” that call other “functions” (…​that call other “functions”, that call other “functions”…​) is one of the primary activites of “real world” programming.

We can now think of functions as a type of instructions that a system understands, which optionally take some inputs, optionally return some values, and optionally change some state:

There are some functions that a system provides for us (like v>^< from our pacman-bot example) and others that we write ourselves, using the system functions, to make our lives easier (like goto! and slope).

We can now think of a “program” as a function of functions (…​of functions …​of functions):

Like the functions inside of it, the “program” function may take some input, change state, and return some output.

For example, a simple program could take in a number and two currencies and return you the result of converting from one currency to another based on today’s exchange rate. A more complicated program might take some input (say, mouse clicks and keyboard button presses) and change the display of the screen to let you play a game.

We’re almost ready to starting learning Clojure proper, we just have one more concept to cover: “data”.

Primitive values are the simplest forms of data; you can think of them as the atoms of the programming world. They include numbers (such as 1 and 1.5), “strings” (which represent text, such as "hello" and "goodbye") and other types of things called “booleans”, “keywords” and “nil”. Let’s take a look at each.

Primitive values are nice, but we often need to deal with collections of values, and that’s where “vectors” and “maps” come in. If primitive values were the atoms of the programming world, then “compound values” are the molecules.

There are more types in Clojure than mentioned here, but these ones will do for now, and we’ll see the others in the future (notably: “sets”, “datetimes” and “uuids”).

A Clojure program is written as text and is composed of "values", "forms", and "symbols". The text that is

"Values" are text that represents data. We spent all of the previous chapter discussing values. Here’s a number: 1, a string: "hello!", and vector of numbers: [1 2 3]

Symbols are text that are used to name things and refer to things that have been named. For example, we could give the vector ["Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" "Sunday"] the name days-of-the-week and later refer to it as days-of-the-week instead of writing it all out again (we’ll cover this in more detail very soon).

A "form" is unit of code that contains values, forms and/or symbols. It is a set of brackets surrounding some content. Here is any empty "form": (). Here is a form with 3 numbers: (1 2 3) Here is a form with 2 numbers and a vector of numbers: (1 2 [3 4]) Here are two forms, one after the other: ("a" "b" "c") (1 2 3) Here is a form within a form: (1 (2) 3) Here is a form with a 2 symbols and a string (println "Hello" name)

A Clojure "program" is a text file that contains one or more forms, values or symbols. Each form can contain one or more forms, values or symbols.

…​and that’s it for the syntax.

In Chapter 1, we discussed how languages define a set of commands that the programmer can call, and if the syntax allows for it, a way to create our own commands (which we called "functions") that are named combinations of the provided commands and/or our own commands.

To start, we will learn X of Clojure’s built-in "commands":

print

(print "Happy Monday "Bob!")

let

(let [name "Bob"] ... )

fn

+

/

if when

map

(let [blah (fn [] )]

)

(defn str→vec [s] (clojure.string/split s ""))

(defn vec→str [v] (clojure.string/join "" v))

(def lookup {"s" "…​" "o" "---"})

(defn char→morse [char] (get lookup char))

(defn text→morse [text] (→> text str→vec (map char→morse) vec→str))

(text→morse "hello world")