The Cleveland CocoaHeads, of which I am a member, started reading Functional Programming in Swift in the past month. I like it so far, but I’ve seen a few statements that, while stated as true facts, don’t seem to be, to me. For example:
“the key philosophy underlying functional programming is that functions are values, no different from structs, integers, or booleans — using a separate naming convention for functions would violate this philosophy”
My first reaction resembled, “Not so, functions are verbs! Those other things are nouns!” Immediately thereafter, I had a reaction to my first reaction which manifested as, “Not necessarily; functions can take arguments. I think the correct term is predicate, not verb.
Let’s get this out of the way first. As far as I know, this is a widely-adopted concept. They look stupid when they aren’t single words, e.g. (camelObject, PascalObject), and that’s not likely to change as long as we’re programming only with text, but otherwise, the names we give to objects look exactly like subjects in non-code text.
Functions are predicates, and vice versa
This Wikipedia entry on predicates in modern theories of syntax and grammar just introduced me to the the idea that
Predicates [are] relations or functions over arguments.
I’m astounded that I only came across this concept now. I don’t have a formal education in Computer Science, but I’m inquisitive, and I’ve been programming for eight years. Grasping this is fundamental to being able to express your thoughts clearly in “code”; the lack of such a grasp of is the source of confusion that leads to all of the worst code I’ve seen.
(Expect examples as I come across/remember them.)
“Translation” from English to Swift is a misnomer
Let’s try to figure out how similar those examples from Wikipedia are, to code we might actually write. I’m changing two things, to eliminate some complexity that we don’t need to deal with at this early stage:
- The tense is changed from past to present.
- The sentence type is changed from declarative to imperative. (I generally try to avoid sending imperative commands to objects that are not “me”, in my code, but I think it’s okay to do it for this simple demo.)
Bob, laugh. → laugh (Bob)
Sam, help them. → help (Sam, them)
Jim, give Jill your dog. → give (Jim, Jill, your dog) is addressed in another article. The possessive determiner makes this example more complex.
It looks like someone has already done a pretty good job of writing “code”, given that I don’t think it was their goal. Let’s compare their “global function” style, to an object-oriented one, altering argument order as necessary, to resemble English syntax. We’ll take out the periods, because these could all be parts of a larger sentence, and capital letters at sentence beginnings, because that doesn’t actually do anything meaningful in English, aside from making up for periods being too small. Also, I’m going to camelCase the names: the conventions I use dictate that Bob and Sam are types of things, and bob and sam are things of that type.
Global English: laugh, bob
Global Swift: laugh(bob)
Object-oriented (OO) English: bob, laugh
OO Swift: bob.laugh()
Global English: help them, sam
Global Swift: help(them, sam)
Object-oriented (OO) English: sam, help them
OO Swift: sam.help(them)
The words are exactly the same! Only the punctuation differs. I’m not ready to amass a list of all punctuation mappings (e.g. invoking predicates utilizes parentheses) at this point, but I’m now under the impression that it’s doable. You’ll see this in action in my future posts, but here’s a start:
The Dot Operator
I think that even these simple examples shed enough light on the dot operator, for it to be worth me talking about now. Although I don’t know what all of them are yet, pondering the OO examples above shows me that It can map to more than one English grammatical construct.
Again, the OO Swift: bob.laugh()
Translate it back into syntactically-accepted English: Bob, laugh.
I think this comma is the easiest way to think about what the dot represents, for this imperative style, but the concept represents a level of grammatical abstraction from what’s really going on, which is an apostrophe and s:
Woo-woo English: Universe, execute Bob’s laugh.
We might be able to improve the first couple of words, but I think they accurately represent what we ask for, in both our programs, and life.
A representation of what Swift compiles to: Execute the instructions at the part of me known as “laugh”, in the area of me known as “bob”.
What we do, with a living Bob, is the same thing. We just don’t hear anybody talking about things this way. As long as we understand that our interactions with other people equate to attempts to program the portion of the universe that they represent, via the universe itself, which is made of us and them, I think it’s fine to use the short form, where the dot operator is a comma. Allow the disguise to simplify, but not confuse.
Where we can go, knowing that the code is English
Before modern tools like Swift, which do a great job of abstracting away what your compiled code will look like, it was forgivable to code-speak in a broken fashion. You could never write anything that the uninitiated could understand, so it was reasonable to assume that the goal was to write as esoterically as possible.
As we move forward, expect one of the next big things in programming to be warnings or errors occurring if your sentence structure is wiggity wack.