The Monologue of Computer Science: Conversational Implicature in Code

First of all, let me give a hat tip to Brad.  This post started as a comment on his excellent post, “The ‘Conversation of Computer Science: How Grice’s Maxims MakeYou a Better Coder” and just grew into another thought.

It struck me while reading Brad’s piece that it’s one thing to impose a set of patterns on a system but another to suggest that those patterns are intended by the speaker and serve a purpose in the conversation.  To this end, I have been trying to find situations where the speaker/coder would deliberately flout one or more of Grice’s maxims in the interest of creating a conversational implicature.

For example, consider a Java method that increments the input by one.  It is possible to write the method in the following way:

                //This method adds one to a number and returns it

                public int addOne(int number) {

                                return (number + 1);

                }

However, someone might choose to write a method with the same functionality a different way:

                //This method adds one to a number and returns it, showing steps

                public int addOne(int number) {

                                int oneGreater = number + 1;

                                return oneGreater;

                }

The second method is less efficient, and it provides more information than is necessary.  That is, the coder is spelling out the thought process that went into the lines of code, and this information is provided along with the literal content of the number being incremented by one.  By giving extra information, the coder flouts Grice’s maxim of quantity.  Several conversational implicatures might be generated; the coder might be a beginner, breaking up the cognitive steps for easier comprehension.  Alternatively, the coder might be making the assumption that the reader is a student, and the steps are for the reader’s benefit.  In this way, the coder/speaker communicates with the reader/listener outside of the at-issue content of the code’s literal function.

Other violations might be more of a stretch.  A coder might flout the maxim of relevance, perhaps, if the object is to write a method to average two numbers and the coder cannot remember the appropriate computation.  In this case, we might see the following lines:

                //This method averages two numbers and returns the result

                public int averageNumbers(int first, int second) {

                                int sum = first + second;

                                int average = eatPancakesThenReturnWithIdeas(sum);

                                return average;

                }

Here, the coder/speaker flagrantly violates the maxim of relevance to draw attention to the lack of functional code.  The conversational implicature is that the coder does not know how to write code that actually returns averaged numbers; this may be intended for a reader or it may even serve as a reminder for the coder.  Either way, it is analogous to a natural language conversation as follows:

                A: What is Paul Grice’s research about?

                B: These pancakes are so buttery!

In this exchange, B flouts relevance, conveying the conversational implicature that B does not know the answer to A’s question and has nothing to contribute to that line of conversation.

However, the above examples are stilted and forced.  In general code conversation, such flouting of the maxims does not occur, which brings me to my point: code is not, in fact, a conversation.  At best, an outside agent poses a question or remark, the coder responds, and a reader receives this response.  The dialogue ends there, which is why I propose that code is in fact more of a monologue.  Instances of Grice’s maxims and even of flouting the maxims are more likely to be imposed by a reader than intended by the coder, and without the intention, they do not have the same significance.