12 February 2009

At the limit

I reread my copy of Gödel's Proof, by Ernest Nagel and James R. Newman. It's a compact outline (102 pages, not counting the back matter) of the work published by Kurt Gödel in the 1930s on the limitations of formal, deductive methods of proof in mathematics. I recommend it to anyone, mathematician or humanist, who is interested in the idea of what it means to say we have proved something mathematically.

In high school, we're introduced to the axiomatic method, usually through a class in geometry. Given the ground rules: definitions of mathematical objects (points, lines), axioms (also called postulates: these are statements to be accepted without proof, like "any two points can be joined with a line"), and a few rules of logic, the student learns to prove more complex statements about the objects. The most interesting, general-purpose of these statements we call theorems, like that of Pythagoras concerning the sides of a right triangle.

While definitions and rules of logic seem to be given to us a priori, our choice of axioms seems to offer some conceptual leeway. Euclid did a lot of good geometry with his five axioms, but mathematicians wondered whether they were the "right" axioms. In particular, would it be possible, given a set of axioms, to prove every true thing that could be said in geometry, or algebra, or arithmetic? In other words, would there be "nothing you can see that isn't shown?"

Gödel answered this question decisively with a No. For a field as seemingly simple as the arithmetic of the integers, no matter what axioms we choose, there will be true statements that can't be proved from those axioms. There will always be a place where "you can't get there from here."

Well, then, we'd at least like to know that the axioms are consistent, that is, that they can't be used to prove contradictory statements. But to know something, to a mathematician, is to prove it. Without, of course, making inferences that assume that it's true already, or using logic more complicated than the original ground rules. And Gödel established that, again for a simple field like arithmetic, its axioms cannot be proved to be consistent using arithmetic's own ground rules.

Nagel and Newman walk the reader through the proof, illustrating some points in detail, skimming over others. In particular, they explain Gödel's clever way of using primes to assign a unique number to every statement in arithmetic. In this way, every logical relationship among theorems and axioms can be represented by a numerical relationship among their corresponding numbers. Their treatment is easy to follow, although the sailing gets a little rough on p. 89, at the crux of Gödel's proof. (My copy includes some loose sheets of notes from my last reading, about 20 years ago, in which I invented some new notation to help me wrap my head around the argument.)

So how does this work apply to software development? Well, for one thing, it establishes an upper bound, perhaps only in theoretical space, on the effectiveness of formal methods of proving program correctness. (Since I've never written avionics software, this isn't a field I spend too much time in.)
Today's calculating machines have a fixed set of directives built into them; these directives correspond to the fixed rules of inference of formalized axiomatic procedure. The machines thus supply answers to problems by operating in a step-by-step manner, each step being controlled by the built-in directives. But, as Gödel showed in his incompleteness theorem, there are innumerable problems in elementary number theory that fall outside the scope of a fixed axiomatic method, and that such engines are incapable of answering, however intricate and ingenious their built-in mechanisms may be and however rapid their operations. Given a definite problem, a machine of this type might be built for solving it; but no one such machine can be built for solving every problem.
Gödel's Proof has recently been reissued in a new edition, edited by Douglas Hofstadter. Andrew Hodges wrote an appraisal of the original 1958 edition, pointing out the proof's direct influence on Alan Turing and computability theory.

02 February 2009

But avoid .Replace()

Jeff Atwood puts the performance meter on various methods of string concatenation in C# and finds that no one has to be a shlemiel.
...you should be more worried about the maintainability and readability of your code than its performance. And that is perhaps the most tragic thing about letting yourself get sucked into micro-optimization theater—it distracts you from your real goal: writing better code.

28 January 2009

Into the blue, too

I see that my old colleague David Alison has emerged from the workshop to launch Shared Status, a refreshingly low-tech small-footprint solution to managing punchlists for distributed teams. It's clearly a tool informed by many hours of sitting through deadly dull, interminable team status meetings. What I think is bold about David's model is that a task is either done or not done. You can hand it off to someone else, but it's still only done or not done. No more cheeseparing about tasks that are 90% complete, forever.

Into the blue

I attended a presentation by Microsoft technology evangelists Ashish Jaiman, Zhiming Xue, and Sanjay Jain to a small group, organized by the IEEE CS local chapter, on Microsoft's Software + Services paradigm and its Azure technology suite. The talk filled in some of the gaps in my understanding.

A key point of the Software + Services model is to characterize the gray area between traditional apps and SaaS apps as either "building block services" or "attached services," with the additional term "finished services" to describe software as a service. But I haven't yet grasped why the distinction is helpful.


Attached services provide a higher level of functionality compared with building block services. Applications leverage attached services to add functionality.


Sanjay demonstrated Microsoft Dynamics CRM 4.0 as an example of a finished service. Surprise, surprise, the extensibility features map on to what I already know from Salesforce.com. I smiled to myself at the naive remark that the features would allow a salesperson to enhance the system "without any programming." (Didn't someone once say that about COBOL?) Last time I checked, there were Dynamics CRM and Salesforce.com consultants making a tidy living.

We moved on to Azure, an "OS for the cloud," and the supporting suite of services on top of it:


  • Live Services: ID and directory
  • .NET Services: service discovery and the "service bus," workflow, access control
  • SQL Services
  • SharePoint Services
  • Dynamics CRM Services


SQL Services is kinda important, because the persistent storage features offered by bare Azure will be hard for the garden variety developer to assimilate: blobs, tables, queues, and locks are all you get. Also rudimentary are the facilities for session management.

And Zhiming noted that e-commerce features like a shopping cart and credit card processing are not there yet, although Microsoft Office Live Small Business can provide them.

He closed with a quick demo of Wikipedia Explorer, one of a handful of apps linked to from the Azure Gallery. The Explorer is actually pretty slick: give it a search term and it produces a network of related Wikipedia articles, rooted on the original term. Also found in the gallery is Steve Marx's blog, which has helpful posts like this one that explain how to go about writing an app for the cloud.

08 January 2009

Finding composites

Another brain-teaser for Jeff and Jefrrey that I missed while my subscription was interrupted: Andrew Koenig reintroduces the 2-3-5 problem, attributed to Dijkstra and Hamming:
Write a program that produces, in ascending order, the sequence of positive integers that have only 2, 3, and 5 as their prime factors. The first such integer is 1 (which has no prime factors at all; hence all of its prime factors are either 2, 3, or 5); the sequence continues with 2, 3, 4 (which has only 2 as a prime factor), 5, and 6. It skips 7, which is prime, continues with 8, 9, and 10, skips 11, includes 12, and so on.