Re: PG: Hackers and Painters / Wright Bros. / CARH

[Dave Long <address@hidden>]

>              But often acts of creation are anti-social in nature as 
> they question socially accepted assumptions. Innovators rarely live at 
> peace with their societies.

Insofar as XP only intends to produce
a servicable product, on budget and on
schedule, it isn't suprising that it
wouldn't appeal to Dichters who are
aiming rather more at Art than Craft.

To my eye, the Wright brothers seem to
have followed a process suspiciously
close to test driven development when
innovating on that flight thing.*

How can we apply the Wrights' manner
of craftsmanship to languages?

Hoare suggests that a good language
(which no doubt includes lightweight
ones) should
> assist the programmer in the most difficult aspects of his art, namely
> program design, documentation, and debugging.

Design
> A good programming language should give assistance in expressing not
> only how the program is to run, but what it is intended to accomplish ...

Documentation
> The purpose of program documentation is to explain to a human reader
> the way in which a program works, so that it can be successfully
> adapted after it goes into service ...

Debugging
> Of course the compiler itself must be utterly reliable, so that its
> user has complete confidence that any unexpected effect was obtained
> by his own program.  And the compiler must be compact and fast, so
> that there is no appreciable delay or cost involved in correcting a
> program in source code and resubmitting for another run ...

Note how tests address all three of
these issues: they express what the
program is intended to accomplish;
they are executable, so adaptations
can automatically be checked; and to
the degree that they are reliable,
they give their users confidence
that unexpected effects are due to
recently added code.

Since tests are a set of executable
statements of intent (written in a
domain-specific embedded language?)
which can be run with the compiler
at compile time, as an extension of
its static checking (via macrology?),
could they profit from some language
level support?

-Dave

:: :: ::

* their predecessors, attempting to
put in all the features first and to
work out the bugs later, learned of
what they'd neglected in design while
several hundred feet up.  Sometimes,
such bugs were fatal.

The Wrights, however, worked things
out near the ground, and as needed.
First they made sure landing their
glider had a solution.  Then they
worked out how to control it while
in the air.  Then they learned how
to take off.  Only after all that
did they put a motor in to take it
"straight through, from the top".

Their process of iterating:
    a) what do we want an airplane to do?
    b) how can we get our airplane to do it?
sounds awfully similar to that of iterating:
    a) what do we want apps like ours to do?
    b) how can we get our code to do it?