The E-Prime of programming?

David MacIver on Twitter remarked that questions of the form “Is X a Y?” tend to be problematic when controversial topics are involved. Consider: “Is Donald Trump a fascist?” “Is string theory a scientific theory?”

The remark reminded me of E-Prime, a modified version of English which attempts to avoid philosophically problematic statements by banning the verb “to be”. The idea is to discourage rigid and dogmatic speech based around statements of identity, like “You are an idiot”. So rather than saying “Season 19 of South Park wasn’t funny”, I might say “Season 19 of South Park didn’t make me laugh much”.

There are a bunch of problems with E-Prime in practice, and I won’t go into those. It’s the idea that’s valuable more than the proposed rule, I think. But on Twitter, David MacIver suggested that in general, “Is X a Y?” is better formulated as “Does X do Z?”

That made some synapses in my brain fire, and I suddenly associated the topic with a totally different area of angry philosophical debate: programming language design.

I’ve been writing quite a lot of Go code recently. Although Go is an object-oriented programming language, it is unlike C++, Objective-C or Java in that it doesn’t have classes. It’s even unlike JavaScript, in that it doesn’t have an inheritance chain at all.

Go OO programming is organized using interfaces. An interface is a set of methods (verbs) representing actions that can be performed by the object. Any object can support any number of interfaces. You don’t specify what interfaces an object supports, either — it implements an interface by actually implementing it, by having the right set of methods, nothing more and nothing less.

So my gzipped.FileServer is a drop-in replacement for http.FileServer not because the code says so, but because both implement the http.Handler interface which allows them to do content-serving-on-the-web things. That interface consists of a single specific method, and I don’t have to declare that I’m implementing the interface, I just do it.

So in Go, you don’t ask what an object is. Rather, you ask what it does. As Effecive Go puts it:

Interfaces in Go provide a way to specify the behavior of an object: if something can do this, then it can be used here.

When you declare a method, you generally declare the interfaces you require from its arguments, not the specific types you expect. For instance, if you were writing code to generate a dynamic web page, you might accept data you want to put on the page as arguments of type Stringer — which means, anything which has a method called String which can be used to obtain a string representation of the object. As you might guess, that encompasses a lot of types of object in Go, from POSIX process states to geometric rectangles.

While you can interrogate the actual type of an object in Go, it’s not something you’re expected to do very often. You can make your functions and methods require specific types, but things start to get messy when you do. I found this way of thinking to be the hardest part to get to grips with when learning Go.

So now I’m wondering: was E-Prime an influence on Go? Are any of the Go team fans of Alfred Korzybski? Or is it just coincidence?

Photo by Sam Thorogood.

One thought on “The E-Prime of programming?

Comments are closed.