I have a job interview this week and one thing they wanted me to know was that they were into Uncle Bob, "Clean code," and test driven development. They were really, really emphatic about Uncle Bob's "Transformation Priority Premise," his notion that you start with failing (broken) code that does nothing, then does one thing, then does a couple of things, each time writing a test that's more and more specific, closer to the full specification of the desired outcome, and in each step making exactly one change to the code, in a prioritized list, to make the test pass.

Bob has a comic in which he illustrates the process. He claims that if you follow the TPP transformations as written you can automatically derive quicksort from a specification about sorting, but if you deviate and choose a later but "easier" transformation you'll end up with bubble sort, the slowest of all the classic sorting algorithms.

Since I've been given a week to cram for this exam, I've been doing exactly that and I have had a number of reactions.

The first is that object-oriented programming as it is traditionally pursued in enterprise deployments is one of the greatest embarassements in human history. Looking at the examples, even the idealized ones, there's so much clutter on the page for error handling that, even with Martin's dictat that code should follow the "functional cores and imperative wrappers" pattern, and all objects should be as SOLID as possible, object oriened programming is noisy, cluttered, and cognitively overloading.

The second is that so many of the TPP "transformation" just don't make sense in a functional programming context. For example, Bob says that you should go:

<code>7. variable → array
8. array → collection</code>

I'm just gonna stare at you in Functor. In functional programming, we learn about scalars and arrays, but very soon we also learn that these are specific instances of a simple idea, the value, and to say that one is more complex than another is a category error (in the ontological sense). It might make sense in practice to treat these as cognitively more complex objects, but in the end the object of functional programming is to abstract that all away and concentrate on the transformations of data qua data.

Transformation number 9 is just as curious:

<code>9. statement → recursion </code>

The higher the number, the less you're supposed to indulge in it, so let's talk about this: why "recursion?" I'm a huge fan of recursion and prefer it to for loops and other imperative constructs, but I'm an even bigger fan of map / reduce / filter and the general power of folds to replace primitive recursion in almost every case. There's an entire programming language built around this idea (Micrsoft's Bosque).

I've spent this weekend in a long plunge back into object-oriented programming The Enterprise Way™, and I've came away feeling like not much has changed since the 1990s. The code is still too verbose, with too many error conditions being handled independently of each other instead of categorically, and with too much code being written about different code paths rather than different expressions. Too many developers of the sort Uncle Bob is trying to reach still think of their programs in Tinkertoy terms: fit the pieces together like a machine, stand the thing up, and hope it works.