Programming languages don’t have adjectives, and related ideas.
I spend much of my time teaching people how to teach computers, with some time teaching people other topics, teaching computers myself, and some teaching people how to teach people to teach computers. This leads me to make an obvious claim:
You don’t talk to computers the way you talk to students.
In particular, today I want to look at what it is possible to say to humans using various programming languages.
A huge majority of programming language expressions are noun phrases. Programmers use noun phrases where speakers would use sentences. For example, we say “the sum of 2 and 3” instead of “add 2 and 3”. This may seem slightly odd, but it isn’t too hard to get used to describing things instead of wording them as requests. But it gets messier when you bump into the common human speak pattern of assertion.
Huge amounts of human speech is made up of assertions. Assertions provide information, they tell the listener something: “I like to write”, “Most visitors ask about the secret passage behind the piano”, “Faulty fuel-burning heaters are lethal”, “2 is greater than 1”. Compared to human languages, programming languages are almost without assertions.
Programming languages have constructs that look like assertions,
but they are not: they are noun phrases instead.
The closest I have come to this in English is to wrap assertions
in the structure “The truth of ‘assertion’.”
So, for example, when in a computer you see
2 > 3
you are actually looking at a noun phrase, “the truth of ‘2 > 3’”,
which is the same thing as simply “false”
in the the same way that “the sum of 2 and 3” is the same thing as “5”.
Some languages do have a construct that looks like you are making assertions; these phrases would translate into English in the form “I assert that noun phrase is true”. But unlike spoke assertions, which are intended to convey information, these assertion-like constructs actually mean “Check if noun phrase is true, and if not freak out.” More on which later.
In addition to assertions, humans ask a lot of questions to one another. Again, computers don’t have these the way we expect either. Where I might ask you “what is your name?” in a computer language I would just write the noun phrase “your name”. Both of these phrases contains an implied request for action: in English I am requesting “Answer the question ‘what is your name?’”; in code I am requesting “Reduce this noun phrase to its simplest form: ‘your name’.” This idea of reducing one noun phrase into another, simpler noun phrase is so widespread in computing that is has several names all its own: “evaluate”, “call”, and “invoke”, each with its own nuances of meaning. There are also lots of other terms related to evaluating (or not) noun phrases, words like “thunk”, “closure”, “lazy”, “promise”, and many others. For the most part, every noun phrase in code is an instruction to evaluate the phrase.
This leads us to one of the only kinds of actual provide-information assertions code has: introducing a new noun phrase and describing how to reduce it to its simplest form. It can be useful to think of these are recipes: A recipe “How to bake a cake” allows me to use the noun phrase “a cake”. These recipes, called functions or methods or procedures or routines or subroutines or coroutines, are part of almost every programming language. In general, programming languages are much better at specifying how-tos than are human languages. The weakness of human languages in providing clear how-to instructions is part of the reason programming languages exist.
Let’s call 3 “Randolph”. If you freak out while reading this section you should calm down, stop reading this section, call 5 “Randolph”, and resume reading with the next section.
In order to write clear how-to instructions, many programming languages add in a few things that are rarely used in speech.
Let’s call noun phrase “name” (forgetting whatever we used to use “name” to mean)
After this step don’t go to the next one in order, go to step name instead
Something went seriously wrong; freak out
If you freak out while you are evaluating code1, calm down and do code2 instead
There’s nothing that would stop use from using these kinds of phrases with humans, but it would be pretty strange to do so very often.
This paragraph is named “Cornflower”
Throughout this post I have used a lot of phrases containing finite verbs in the second person: in other words, instructions to you, the reader. “Evaluate”, “reduce”, “call”, “go”: they all have this form. Eventually, the point of any programming language is to tell the audience (generally a computer) exactly what to do. We use noun phrases and definitions and so on because they are pleasant to write, but eventually it all gets turned into a lot of requests to add things and remember things and send particular voltages along particular wires.
Some languages, such as Haskell, strive really diligently to have only noun phrases, no instructions at all. Others, such as Assembly, use almost only direct instructions. Which one you pick is a matter of choice (often very passionate choice), bu not matter the choice you won’t be writing conversations in code.
Stop reading. You have reached the end of this blog post.
There are lots of things that human languages have but code does not. For example, in the phrase “a sweet cake” it is not obvious how evaluating that phrase would be different from evaluating “a cake”. What did the adjective mean?
There are a lot of -oriented languages out there; object-oriented is the most popular, though hardly the only one. One way of thinking about these languages is as efforts to add more parts of human language to code. Interfaces and subclasses, for example, both get at parts of the idea of adjectives. These efforts have varying levels of success; I generally like them once I understand how they map to lower-level ideas, though I often find their almost-but-not-quite approximations of human language confusing at first.
If “Randolph” ≥ 4, continue reading with paragraph “Cornflower”.