Language, Programming, and Creation

We usually think of poets and engineers as mutually exclusive types casting suspicious glances at one another across the academic canyon that separates the Humanities and Sciences.  There are some excellent reasons for that. Lewis Carroll can write:

’Twas brillig, and the slithy toves

      Did gyre and gimble in the wabe:

All mimsy were the borogoves,

      And the mome raths outgrabe.

And we get it, even though we don’t get it. Carroll has created an image of some vague things moving around in an environment.  He has created something with words; but if it were a bridge, you wouldn’t walk across it without a life-vest.  In the same way, you might not invite the kid who was taking apart the toaster at five years old to write a poem for your wedding.

But this dichotomy between the freewheeling poet and the disciplined engineer is mainly illusory.  We all get to be good at language for free, at least one language anyway.  We know the rules so well, and so implicitly that we can play around in what feels like complete freedom.  But if you’ve ever had the experience of learning another language as an adult, you know that languages are chock-full of rules, restrictions, and we-just-don’t-say-it-like-that’s.

If you’ve taken the time to learn another language’s funny shapes and pesky rules, you have already extended your hand over that tremendous intellectual divide. And, believe it or not, there are a few “sciency” types out there on the other side reaching out towards you too.

At the beginning of their book Structure and Interpretation of Computer Programs, the authors, who were all undoubtedly taking apart toasters in kindergarten, describe programing as sorcery:

“The programs we use to conjure processes are like a sorcerer’s spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform.”

To put it another way, programming allows you to create things with words, even silly and pointless things. 

To oversimplify a bit, these “spells” are composed of two essential elements: nouns and verbs.  I’m sorry, I meant to say: data and procedures. Let’s flesh that out.

In the beginning (or a few days later), there was Man. The first instance of the kind “Man,” or Mankind for short, was Adam. If that part of Genesis were written in Python instead of Hebrew, it might look like this:

class Man:

def __init__(self, name):

    self.name = name

    self.hasEatenTheApple = False

adam = Man(“Adam”)

Don’t worry about the syntax right now. New languages often look and sound very strange at first. The important point is that our “adam” is now the first of his kind, but he’s just a lump of clay with a couple of attributes (name and hasEatenTheApple–mercifully false at the moment).  As you might have heard, Adam did more than just sit there; he also ate an apple. Let’s go ahead and add a verb to our little conjuration:

class Man:

 def __init__(self, name):

  self.name = name

   self.hasEatenTheApple = False

def eatsTheApple(self):

   self.hasEatenTheApple = True

adam = Man(“Adam”)

Now our “adam” has a verb (eatsTheApple). Or maybe it’s better to say that he has the potential to perform the action eatsTheApple. Let’s not get into free will.  

As is often the case with natural languages, verbs act on other nouns, which then become “objects.” In this case, our verb (eatsTheApple), when performed, acts on the noun hasEatenTheApple and changes it–for the worse.

We can then freely render this sentence.

English:  Adam eats the apple.

Pythonish: adam.eatsTheApple()

And it’s all downhill from there.

Of course, knowing what a noun is doesn’t make you an expert in Chinese any more than knowing what a piece of data is makes you a Pythonista. But knowing what nouns and verbs are, and being able to adapt to a strange system of signs and rules will give you a leg up as you climb the walls of Doune Castle (that’s a Monty Python reference–you’ll get tired of those).

But don’t go getting a big head about it just yet; even with previous experience learning another language, there is still much work to be done. You can’t just stick your hand out; you have to get your ass over the wall too.

Chad Mowbray is an instructor for Code Platoon’s Evening and Weekend Program. He was a paratrooper and Arabic translator in the 82nd Airborne Division. He eventually found his way into a Ph.D. program at the University of Chicago studying classical Arabic poetry. But after starting a family, Chad inexplicably developed an appreciation for suburbs and retirement accounts. After graduating from Code Platoon, he worked as a DevOps engineer at Motorola Solutions and is currently a data analyst and digital pedagogy fellow with Academic Technology Solutions at the University of Chicago.