This rings of interesting mathematical content, but then thuds right at the end. This sort of process doesn’t produce a proof at all (or at least no interesting ones) as it is a development of a theory and there isn’t even a statement of a property to be demanded (besides the tests passing themselves, and no proof there either).
But what is going on is the interesting countermelody of theory and model. It’s easy to note that as one adds more constraints to a problem the space of validatable solutions is whittled away. This process is a driving process in mathematics at large and especially well known to mathematical modelers. It should be no surprise at all to find it arising in computer programming.
What’s interesting, however, is the author’s conclusion that the order of priority should be derived according to the principle of making the smallest possible change at each point. My first reaction was to say that this is a little foolish since the history of mathematics is based upon finding the intensification of a spec which leads to the most fantastic structures of models. For instance, moving from the theory of monoids to the theory of groups changes a more or less boringly enormous space of models to one with incredible structure (see Monstrous Moonshine).
I was talking with Gershon Bazerman in Boulder after Lambdaconf a few days ago and he discussed Lawvere’s essentially communist interpretation of this—that his goal is to seek the essential struggle between specifications where two nigh contradictory demands establish a wide and fascinating new pattern.
Uncle Bob here seems to eschew this with his Priority Order. It feels as though his indenturing to the red/green/refactor cycle demands it of him. But I also have another interpretation on further thought.
Both Math and Programming play a similar game of being bound only by our imagination. But, when programming one’s bounds are immediately satisfiable. The computer executes what you tell it to no matter how silly or wrong. On the other hand, mathematicians must always pay a mental tax for the complexity they introduce since it is on their shoulders to painstakingly determine its consequences.
To this end, mathematicians always disfavor some kind of complexity to a degree far more intense than red/green/refactor can force. But it is also of a different form. They disfavor compression-free complexity as it is difficult or impossible to hold in their minds or communicate. This actually drives mathematicians to seek things outside of priority order sometimes when it can lead to one of these Lawvereian “essential struggles”. To them, the priority order is probably “sometimes correct”, but certainly not something to tie yourself to.
Personally, I believe that the mathematician’s objective function is an important if not crucial one for programmers to hold as well. Our ability to communicate code plays out both for computers and for humans and I believe there is a more fundamental beating heart to why this is what one should optimize for. “Speed to Green” is a pale imitator. But, even using such a thing you can still find another kind of essential tension between specification and model space. It’s interesting to read these reflections upon it.
This rings of interesting mathematical content, but then thuds right at the end. This sort of process doesn’t produce a proof at all (or at least no interesting ones) as it is a development of a theory and there isn’t even a statement of a property to be demanded (besides the tests passing themselves, and no proof there either).
But what is going on is the interesting countermelody of theory and model. It’s easy to note that as one adds more constraints to a problem the space of validatable solutions is whittled away. This process is a driving process in mathematics at large and especially well known to mathematical modelers. It should be no surprise at all to find it arising in computer programming.
What’s interesting, however, is the author’s conclusion that the order of priority should be derived according to the principle of making the smallest possible change at each point. My first reaction was to say that this is a little foolish since the history of mathematics is based upon finding the intensification of a spec which leads to the most fantastic structures of models. For instance, moving from the theory of monoids to the theory of groups changes a more or less boringly enormous space of models to one with incredible structure (see Monstrous Moonshine).
I was talking with Gershon Bazerman in Boulder after Lambdaconf a few days ago and he discussed Lawvere’s essentially communist interpretation of this—that his goal is to seek the essential struggle between specifications where two nigh contradictory demands establish a wide and fascinating new pattern.
Uncle Bob here seems to eschew this with his Priority Order. It feels as though his indenturing to the red/green/refactor cycle demands it of him. But I also have another interpretation on further thought.
Both Math and Programming play a similar game of being bound only by our imagination. But, when programming one’s bounds are immediately satisfiable. The computer executes what you tell it to no matter how silly or wrong. On the other hand, mathematicians must always pay a mental tax for the complexity they introduce since it is on their shoulders to painstakingly determine its consequences.
To this end, mathematicians always disfavor some kind of complexity to a degree far more intense than red/green/refactor can force. But it is also of a different form. They disfavor compression-free complexity as it is difficult or impossible to hold in their minds or communicate. This actually drives mathematicians to seek things outside of priority order sometimes when it can lead to one of these Lawvereian “essential struggles”. To them, the priority order is probably “sometimes correct”, but certainly not something to tie yourself to.
Personally, I believe that the mathematician’s objective function is an important if not crucial one for programmers to hold as well. Our ability to communicate code plays out both for computers and for humans and I believe there is a more fundamental beating heart to why this is what one should optimize for. “Speed to Green” is a pale imitator. But, even using such a thing you can still find another kind of essential tension between specification and model space. It’s interesting to read these reflections upon it.