I’ve also been learning the warts of the Hadoop implementation of the map-reduce paradigm. Map-reduce treats a “key-value” pair as such a reliable primitive that I found myself surprised that it wasn’t spelled out (it seems to be in MRUnit, but Hadoop uses Mapper<K1,V1,K2,V2>, not Mapper<Pair1,Pair2>) — and further surprised to find that it is absent from the Java core. I’m surprised, really, because the notion of a strongly-typed, heterogeneous, ordered list (a tuple) is so instrumental in lambda calculus. That explains, of course, why it’s present in Scala and other strongly typed languages, but seems like a surprising omission in Java.

Finally, a different sense of “pair” — I really like doing creative new software work with other people.  It’s been clear to me for a long time that software is a conversation with others, but I’m coming to terms with the idea that design of interesting new software is better if done as an encoding of at least two people’s ideas — at least, when both of those people are interested in design (Bill, I’m looking at you.) Wikipedia says it thus: “The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.” I always like those tasks better anyway.

As an afterthought, and as part of wondering why it was so important to me, Bill and I worked out that a “key/value pair” (the initial Hadoop-based reason for getting into this) is effectively a Saussurean sign. Because we are not masochists [well, usually], we declined to share this insight with our non-philosophically-oriented colleagues, but I keep it in the back of my mind for remembering why the lambda-calculus geeks get along so well with linguists — computational or otherwise.