Temba, His Arms open()

Languages have rules about how their words or signs fit together (syntax). They have patterns of how their words or signs tend to sound or look, how some elements are built out of others, and how poets break the rules to make things interesting. One can have words or signs that look like they belong to a language, are sequenced, conjugated, declined, and capitalized correctly, and yet are not valid examples of that language. Likewise, one can have elements of a language used correctly according to those rules, but their combination has no meaning¹ according to its semantics, even to poets²

Software .. [are] systems of meaning – Kevlin Henny

Software languages, while using words from human languages, are even more rigid in their grammar, syntax, and context, and still can hide incorrect meanings in technically-correct text

This And That #

Even seemingly obvious things like conjunctions are not safe. Logical (computer programming) languages have very specific meanings of the words “and” and “or”. In English, one might say “Find all the doctors and dentists”, which one might translate into a logical expression like

where profession = “doctor” AND profession = “dentist”

However, it should be

where profession = “doctor” OR profession = “dentist”

The meaning of “and” in conversation is like a mathematical union: this set of people, who are doctors, and that set of people who are dentists. In software, one must be clear on the context. The definition of “doctor” might be someone whose id is in the set of doctor ids, or it might be someone whose profession attribute is the string “physician”. The context of data is not the same as the context of a conversation

Do You Walk to School or Do You Take Your Lunch? #

Likewise, combinations of “and” and “or” are lexicographically ambiguous, but in conversation, one infers the meaning by context or domain knowledge: “Get three oranges or tangerines and a dozen eggs” would rarely result in omitting the eggs if tangerines are unavailable, but computer code can have this sort of vaudeville/sitcom misunderstanding. Most logical and computer languages have an order of operation that ensures that, without parentheses to explicitly group operations, AND happens before OR: tangerines and eggs before oranges or ...

What Language Are You Using? #

Cucumber is a testing tool that stores its tests in English-like phrases³. For example:

Given I am accessing the system with proper authentication
When I shall transfer with enough balance in my source account
And the destination details are correct
And I supply the correct transaction password
And I press or click the send button
Then amount will transfer
And the event will be logged in the log file

It looks like English and reading it conveys most of its meaning, but not all of it because the tool does not understand English. It does not know what “destination details” or “are correct” mean. Programmers defined all those strings of characters to mean some specific coded behaviours that might not have anything to do with the words in those strings (although they generally do). Cucumber offers syntactical “sugar” to allow the rule to read like an English sentence by interpreting “the destination details are correct” as set_correct_destination()

It Reads Better Than It Writes #

As with human languages, it’s easier to understand than to compose. English semantics apply when a human is reading these rules, but only the semantics explicitly created for this use of the Cucumber tool apply when writing rules. While any English speaker will understand “I supply the correct destination details” means the same thing, in this context, as “the destination details are correct”⁴, this system will not understand because the strings are not identical

This “natural language interface” is a cargo-cult use of English, somewhat like COBOL’s

“COBOL statements have an English-like syntax, which was designed to be self-documenting and highly readable”⁵

The English syntax and tokens (words) make it easy to read for many, but much of the information is implicit and hidden (e.g. what “correct” really means). It hides the way programmers think about rules and steps, which is different than how others (product managers, customer support, designers) think about them

Rails uses more words than symbols or notation to encapsulate meaning. Instead of memorizing and referencing a collection of function names, Rails uses simple nouns, verbs, and symbols, as well as an expectation of what the user will name their types. This results in code that resembles English sentences but has grammatic idiosyncracies of any other programming framework

expect(response).to have_http_status 200
expect(json).not_to be_empty
expect(json[‘id’].to equ(expected_id)

For example, most Rails methods that might raise an error end with an exclamation mark. These all have non-exception-raising versions of the same name without the exclamation mark. However, the method find will raise an exception RecordNotFound, while find_by_id does not. This difference is not intuitive or inferrable; it’s Just The Way It Works. The worst sin is thinking that the English syntax allows non-programmers to code “because it’s just English”

Programming is not just knowing a language or symbols; it’s how one thinks⁶

Expert knowledge of English grants one no more expertise in Cucumber, Rails, or COBOL than a precocious child familiar with blocks can build a shopping mall. Just as the map is not the terrain⁷, the terminology is not the meaning