It needs to be said: the quality of a programming language is not inversely proportional to the number of bytes needed for a Sudoku solver. Not that there's anything wrong with comparing Sudoku solvers; they can contrast certain aspects of languages, and differing solution styles can help readers think differently about code. But this only gets us so far.

The problem is the public language debate rarely ranges to topics that span more than a couple dozen lines of code. Anything bigger is difficult to manage in a single discussion. Therefore we need a model to debate the higher-order concerns of programming languages. Fortunately, I'm shameless, and will shamelessly steal such a model from Donald Norman's excellent Design of Everyday Things.

The idea I'm referring to is Norman's modeling of human interaction with software and physical tools as a series of imperfect approximations to approach a perfect goal. A system should assume all user input is imperfect, but guide the user to her goal. A user should have feedback indicating progress toward the goal. Mistakes should be easily reversible and never take her far astray.

Let's apply this to programming languages and practices. The biggest step forward in recent years has been the adoption of test-driven development. This fits nicely -- a solid safety net of unit tests allows developers to move towards the perfect goal. It also brings to mind a humorous recent post by Jt Gleason. One of the reasons programming is harder than bridge building is even small defects can cause us to jump radically away from our goal.

So, what can improved languages and practices do to help? They can guarantee no programmer mistake will cause us to jump to across an ocean, to use Gleason's metaphor. Programming will never be truly analogous to bridge building, but if bugs can be localized -- like how a bad bolt is localized for a bridge -- we might make progress. We can't eliminate bugs, but we can bound them and trend towards perfection. This reminds me of a Piet Hein poem reportedly displayed in Donald Knuth's home:
The road to wisdom? Well, it's plain
 And simple to express:
Err
and err
and err again
but less
and less
and less.
With all this in mind, I recently saw something that just might be a glimpse of the future. Giles Bowkett posted a screencast showing modification of code in a Seaside-based web application as it was running. Sure, we've been able to hot-swap code for a while, but that's usually a painful process requiring specific launch configuration and use of an external debugger. Imagine if every menu in every program had an "edit" button available to experts, allowing them to adjust code on the fly. The code-build-test-debug loop would become instantaneous, applications could be grown in the context of existing pieces, and good design and languages can prevent local bugs from creeping elsewhere. This is our series of approximations toward a perfect goal.

Of course, the above ideal might be unachievable for many applications. Even so, it still might be possible to build an imperfect approximation.