https://www.dreamsongs.com/ArtOfLisp.html
[DreamsongsBannerWeb]
The Art of Lisp & Writing
Ignorance more frequently begets confidence than does knowledge.
Charles Darwin
Lisp is the language of loveliness. With it a great programmer can
make a beautiful, operating thing, a thing organically created and
formed through the interaction of a programmer/artist and a medium of
expression that happens to execute on a computer.
Taught that programming or the worse "developing software" is like a
routine engineering activity, many find difficulty seeing writing as
a model or even a metaphor for programming. Writing is creative, it
is self-expression, it is art, which is to say it isn't a science and
unlike science and engineering, it isn't a serious activity.
Judgments like this, though, are easiest made by people who don't
seriously engage in making both science and art. Art, engineering,
and science are in that order part of a continuum of finding truth in
the world and about ourselves.
Artists make things and have always done so, gathering knowledge.
There is sometimes no other purpose for what artists make than the
need to embody an artistic statement in some form perhaps in an
artifact or perhaps on paper. When an artist makes something, he or
she is drawing on two parts (at least) of the world at the same time:
the part that is driving the construction which could be thought of
as being within the artist in a sense, and the part that is in the
world providing the substances that combine under physical laws to
become the artistic artifact. The least bit of artistic
knowledge-making is that the artist is, in making the thing, making a
map of what is possible and how the physical world relates to the
metaphorical, imaginative, and interior worlds of people. And the
other extreme is that in trying to make something perhaps grand, the
artist is stretching what people know about the world. Even today
there is debate about how some artistic structures were made by
ancient artists. Artists discover the properties of the world.
Artists who create by writing or producing other representations of
what the world is or could be are also laying out a map for how the
world could become, and in cases where artists need technological
explanations in their stories and myths, scientists and engineers in
many cases explore how to build what they were delighted to learn
about as children or adults from the dream-makers. For example, in
1587 someone published a set of tall tales about a possibly
historical man known as "Faustus" in a book that came to be known as
German Faustbuch or Historia von D. Johan Faustus. The Faustbuch was
translated and changed by a man known only as "P. F." in 1592 into
the English as The History of the Damnable Life and Deserved Death of
Doctor John Faustus. In this book Dr. John Faustus rides a wagon
pulled by dragons to the sun. And as time went on, engineers and
scientists worked on and devised flying machines, as commonplace
today as were sailing ships in the 16^th century. Is it a coincidence
that cellphones look suspiciously like Star Trek communicators? We
can see an early fascination with traveling beneath the sea in the
story of Jonah and in the legend of Atlantis. Greeks and Romans wrote
about diving bells, and so did medieval writers.
As people need or want to do things with materials and the world,
people with special skill take the fore and devise or discover how to
manipulate the physical world to make those things. To avoid future
mistakes, these makers write down rules of thumb, patterns of
creation and making, and safety factors as a practical matter. Today
we call them engineers. When we think of engineering today we think
of carefully planned scientific engineering such as building bridges,
where it is a fairly linear though costly and complicated process to
go from the planning stage to a completed bridge. We forget the
centuries of tinkering with bridge design in prehistoric and ancient
times when bridges were gingerly tested as designers searched for
principles. Even still, on November 7, 1940, at 11:00AM, the Tacoma
Narrows Bridge collapsed from wind-caused vibrations after being open
to the public for a few months, showing that even sophisticated
engineering techniques one could even call them contemporary
engineering techniques can fail.^+
Nevertheless, engineering knowledge has usually preceded scientific
knowledge and often has remained constant while scientific theories
about the engineering materials came and went. "Engineers" were able
to create sophisticated fires for cooking and metal working using
chimneys and other forms of forced oxygen for centuries while
scientists flailed from theory to theory. For example, while advanced
fire-based engineering was going on in the 6^th century BC in Greece,
Anaximenes's theory was that the source or nature of the cosmos was
aer (air). Aer was constantly in motion. When aer expanded it became
aither (ether: bright fiery air as on a clear day); when it expanded
further, it became fire. As aer condensed it became clouds; further
condensation led to water, ice, earth, and finally rock. Throughout
history there have been various theories of what fire was;
nevertheless, the chimneys and other artifacts of working with fire
remained constant and working properly.
Scientists come along at the end; they take what artists and
engineers have found out or dreamed about the world and try to weave
a simplified narrative that explains it all. Scientists need to find
the small set of facts, conditions, laws, forces, and principles that
cause the beautiful complexity we experience. Since Galileo they have
agreed to use mathematics as the language of scientific knowledge.
Scientists, though, perhaps because of their desire for accuracy and
precision have had the worst luck of all in pinning down the truth of
the universe. Philosophers and historians of science have pointed out
and speculated on how scientific theories come and go through
refinement, through revolution, or even through anarchy.
As the 20^th century proceeded, for example, the theory of quantum
mechanics and the expanding plausibility of complexity science threw
everything we knew about the world into doubt, rendering many of our
best theories approximations at best, or at least opening the door
for a new kind of formulation (other than mathematics) for describing
the truth about reality.
Perhaps it's because they are the most consistent losers when it
comes to understanding the world that we love scientists so much,
tell them constantly that they are the only true beacons we have
pointing out what is true; we shower them with grants and money for
large experiments and take away funding from the arts.
Well, let's look at the more successful branches of human endeavor:
art and engineering. I was recently reading about writers and
mapmakers. Writers, of course, are among the most imaginative
creators of false realities, meaning that they create worlds and
characters that are almost like the real thing, but nowhere will we
ever find those places or people or circumstances. We might be
tempted to call them liars, but even though all the details are in
essence not representative of a particular reality, what is contained
in their work is essentially true there may not be a Nick Adams and
neither a Big Two-Hearted River in Seney, but Heminway captured
something about real life that makes his story not a lie.
A mapmaker, though, is a kind of engineer designing and creating
representations of the real world for a purpose, usually the purpose
of understanding the lay of the land or how to get from one place to
another. A mapmaker strives for accuracy and precision in
representing the geography of the world. Right?
Not really. First, maps of regions of the earth involve some sort of
mathematical projection which, unless understood in a way probably
few people can, distorts some aspect of reality significantly. The
Mercator projection represents constant bearing paths such as sea
routes as straight lines, but whereas meridians converge at the
poles, in the Mercator projection they are parallel. Further, length
and area are not preserved.
If a mapmaker makes a local map, the surrounding areas are left out,
as if they don't exist. If the map is a of a political area, it might
leave out places important to people living there especially in
gerrymandered political regions.
A mapmaker's skill lies in knowing how much detail to show and where
to leave things out or even tell lies. The following is perhaps one
of the most useful maps in the world today. It depicts the London
underground transportation system the Tube.
[tubemap2]
This map is indispensable even while it totally distorts the
geography and geometry of London. Using a ruler to measure distances
or using a compass to determine headings is useless. Almost all of
London is left out. The Thames, for example, more closely resembles
heat ducting in a remodeled London warehouse than it does the famous
river or any river for that matter.
Perhaps mapmakers are liars, too.
Novelists and especially short story writers not to mention poets who
do it the most are in the same business. There simply cannot be
enough detail in a story to be any sort of accurate representation of
the actual world. Many characters in stories apparently don't work,
don't eat, don't go to the bathroom, don't pay bills, don't work out,
don't shop in fact, all that they do is what's connected with the
story and what we need to know as readers about them. We don't know
where some characters live, what their childhoods were like, where
they grew up, what they look like, or even sometimes their names.
Fictional worlds are partly real, mainly made up, and almost entirely
left out. In this, writers' work resembles mapmakers'.
These skills are the skills of guiding they are the skills of
perfecting the presentation of the finished product. For the
mapmaker, the available tools include existing maps, computer-aided
design tools, and the talent and skill to know what a map is for and
how to create one that serves that purpose for human consumption.
In contrast, the writer has only his or her skills; pens, pencils,
computers, and paper; and the language for simplicity let's say it's
English he or she is writing in. The act of creating a good
presentation of a story is the act of writing followed by revision.
The writer is guided by the many thousands of writers and stories
that have come before, the conventions of the culture, and the
extensive reading skills the audience can be expected to have.
But neither writing nor mapmaking are simply guiding. Guides need to
have knowledge of their landscapes, and such knowledge comes from
exploration and discovery.
Obviously gathering the knowledge needed to make a map is discovery
in fact, when asked to list the best known explorers we think of
people who have explicitly set out to complete a map, where a map
includes everything that is found there not simply the land and its
features but the people, towns, cities, roads, resources, minerals,
crops, climate, and local flora and fauna. Christopher Columbus,
Ferdinand Magellan, Marco Polo, Lewis and Clark. To explore, one
simply goes and observes. To find out what's on the other side of a
mountain range, one just goes there; to see what an island has to
offer one simply wanders. But these acts of going and wandering
require also noticing and noting.
Most of exploration is in the nature of the locally expected: What is
on the other side of that hill is likely to be a lot like what's on
this side. Only occasionally is the explorer taken totally by
surprise, and it is for these times that many explorers live.
Similarly for writers: What a writer thinks up in the next minute is
likely to be a lot like what is being thought this minute but not
always: Sometimes an idea so initially apparently unrelated pops up
that the writer is as surprised as anyone. And that's why writers
write.
Richard Hugo, the 20^th century poet and writing teacher wrote about
the use of triggers in creative work. A trigger is any idea, scene,
image, thought, sound, smell, or memory that by its "appearance" in a
mind causes that mind to create something. A trigger can end up being
a metaphor, a reminder, a stepping stone, an association, or anything
that sparks connections to the creative mind. Hugo almost goes so far
as saying that all creativity is really just an ability and
willingness to take up the thread a trigger provides.
A poem can be said to have two subjects, the initiating or
triggering subject, which starts the poem or "causes" the poem to
be written, and the real or generated subject, which the poem
comes to say or mean, and which is generated or discovered in the
poem during the writing. That's not quite right because it
suggests that the poet recognizes the real subject. The poet may
not be aware of what the real subject is but only [has] some
instinctive feeling that the poem is done.
Richard Hugo, The Triggering Town
Writing, then, can be viewed as two acts put together: the act of
discovery and the act of perfecting the presentation. One seems
creative and the other analytic, and therefore, it would seem to make
sense to separate them, using the best tools for each, maybe even
using the best people for each. This is where some of our software
methodologists have landed.
But for almost all writers, the act of discovery is mixed up with
the act of perfecting the presentation, because the actual words
and the need to select and prune act as triggers and forces on
the material in ways that can both require more discovery and
cause it whether required or not. And so while each writer may
always start with an act of discovery and always end with an act
of perfecting, the proportion of each type of act and the order
in which they appear will be otherwise as varied as possible. We
might be able to say that the statistical behavior of writers
shows that more acts of discovery take place near the beginning
and more acts of perfecting take place at the end, but this is
unimportant information for any particular writer. It can be
argued that all writing is creative writing, since if one is
writing the way one should, one does not know what will be on the
page until it is there. Discovery remains the ideal.
Richard Hugo, The Triggering Town
Writing a beautiful text takes sitting before a medium that one can
revise easily, and allowing a combination of flow and revision to
take place as the outlines and then the details of the piece come
into view. Changes are made as features of the writing emerge first
the noise, then the sense, the force, and then the meaning and the
work of the writer is to continually improve the work until it
represents the best words in the best order. Great writing is never
accomplished through planning followed by implementation in words,
because the nature of the word choices, phrasings, sentence
structures, paragraph structures, and narrative structures interact
in ways that depend of each other, and the only possible plan that
can be made with which a writer can "reason" about the piece is the
piece itself.
This is true of all creative making flow and revision are the
essences. Flow is the preferred state of mind for the writer doing
discovery. Flow means that there are no barriers between the movement
of the mind and the placement of words on the page. When in flow, the
writer feels as if he or she is in a vivid and continuous dream in
which the relevant parts of the dream flow onto the page.
Revision includes reading material already written and perfecting it
as presentation, but as the name suggests, it is more. Discovery is
always mixed in with perfecting, because, as Hugo says, "one does not
know what will be on the page until it is there." Moreover, revision
when performed courageously involves determining what to leave out,
just as the mapmaker determines what in the real world can remain
unmentioned and unrepresented for a map made for a particular
purpose.
For many, this will not sound as if I am describing programming or as
some like to put it: software design and implementation. To satisfy
the biases of such folks, I will use untypical words and phrases for
concepts that have acquired too strict a meaning.
Following the lead of Paul Graham, I will call Lisp a programming
medium to distinguish it from languages like Java which is a
programming language.
Very dynamic languages like Lisp, TCL, and Smalltalk are often
used for prototyping. One of the reasons for their success at
this is that they are very robust.... Another reason ... is that
they don't require you to pin down decisions early on. Java has
exactly the opposite property: it forces you to make choices
explicitly.
James Gosling, Java: An Overview
The difference between Lisp and Java, as Paul Graham has pointed out,
is that Lisp is for working with computational ideas and expression,
whereas Java is for expressing completed programs. As James says,
Java requires you to pin down decisions early on. And once pinned
down, the system which is the set of type declarations, the compiler,
and the runtime system make it as hard as it can for you to change
those assumptions, on the assumption that all such changes are
mistakes you're inadvertently making.
There are, of course, many situations when making change more
difficult is the best thing to do: Once a program is perfected, for
example, or when it is put into light-maintenance mode. But when we
are exploring what to create given a trigger or other impetus when we
are in flow we need to change things frequently, even while we want
the system to be robust in the face of such changes. In fact, most
design problems we face in creating software can be resolved only
through experimentation with a partially running system. Engineering
is and always has been fundamentally such an enterprise, no matter
how much we would like it to be more like science than like art. And
the reason is that the requirements for a system come not only from
the outside in the form of descriptions of behavior useful for the
people using it, but also from within the system as it has been
constructed, from the interactions of its parts and the interactions
of its parts separately with the outside world. That is, requirements
emerge from the constructed system which can affect how the system is
put together and also what the system does. Furthermore, once a
system is working and becomes observable, it becomes a trigger for
subsequent improvement. The Wright Brothers' first flying machine
likely satisfied all the requirements they placed on it, but they
were unwilling to settle for such modest ambitions and neither was
the world and even today we see the requirements for manned flight
expanding as scientific, engineering, and artistic advances are made.
Christopher Alexander spoke of these issues as follows while
discussing an initial Bay Area Rapid Transit ticket booth design
study he did early in his career:
So it became clear that the free functioning of the system did
not purely depend on meeting a set of requirements. It had to do,
rather, with the system coming to terms with itself and being in
balance with the forces that were generated internal to the
system, not in accordance with some arbitrary set of requirements
we stated.... What bothered me was that the correct analysis of
the ticket booth could not be based purely on one's goals, that
there were realities emerging from the center of the system
itself and that whether you succeeded or not had to do with
whether you created a configuration that was stable with respect
to these realities.
Christopher Alexander
What bothers and surprises me that so many software developers,
managers, and thinkers don't appear to understand this point. James
Gosling in talking about Java acknowledges that at least the
object-oriented notion of late or dynamic binding is important to
support shipping new (though constrained) versions of libraries and
to make derived classes, but he seems to forget that the malleability
of the medium while programming is part of the act of discovery that
goes into understanding all the requirements and forces internal or
not that a system must be designed around.
As a system is implemented and subjected to human use, all sorts of
adjustments are required. What some call the "user interface" can
undergo radical reformulation when designers watch the system in use.
Activities that are possible using the system sometimes require
significant redesign to make them convenient or unconscious. As
people learn what a system does do, they start to imagine what
further it could do. This is the ongoing nature of design.
We see it at work in writing as well. As the writer reads what's been
written, changes come to mind improvements based on writing gone
awry, better words popping up, imperfections, wrong turns, too much
left out, too much detail creating distractions, better approaches,
or even better ideas and directions. The acts of discovery and
perfecting merge for the writer, and for this to happen it is
essential that the medium in which the creation is built be the
medium in which it is delivered. No writer could even begin to
conceive of using one language for drafting a novel, say, and another
to make its final form.
Many writers share drafts with other writers to get more eyes and
minds involved. There is a tradition of writers' workshops for
helping a writer see what the work really is, to understand how
readers will approach it, what will be clear and what obscure. Like
the mapmaker, the writer wants to find out how travelers will get on
in the newly created world. And at any point, the process of
discovery can kick in again.
Like many types of artist, the writer is manipulating during the
discovery and perfecting stages the very material that represents the
work when complete. In the old days, the manuscript would be retyped
or typeset, but not so much anymore. The word "manuscript" itself
refers to the (hand written) copy of the work before printing and
publication, which the writer constantly revises. But the manuscript
which is constantly worked over differs from a published work only by
finally pinning down decisions like fonts, page breaks,
illustrations, and design elements.
[Break2]
The distinction some make between prototyping and software
development has vexed me my whole career. I have never seen a version
1.0 of a system that was acceptable. I find that every software group
messes with the software up until the very time it's deployed or
delivered. At the outset the developers want to get something running
as soon as possible they are interested in leaving things out that
are not necessary to the purpose of understanding the internal forces
and external reactions affecting what has been built. When
prototyping was considered part of the development process, people
spoke of prototyping languages or languages good for prototyping as
an ideal. Though these times are long past, software developers still
need to go through the same steps as prototypers did and for the same
reasons, but what these developers are using are delivery languages
or languages designed to describe tightly a finished program.
The idea behind a description language is to create the most complete
description of a runnable program, primarily for the benefit of a
compiler and computer to create an executable version of it that is
as efficient as it can be, but sometimes also for readers who will
perhaps be enlightened by knowing all the details of the program
without having to do a lot of thinking.
I like to think of a program written in one of these languages as a
"measured drawing." A measured drawing is a set of plans made by a
craftsman of a piece of furniture, for example, which enables an
amateur to make an exact copy. Whereas a master craftsman will be
able to take a rough drawing or an idea of such a piece and by virtue
of his or her expertise make a perfect specimen, an amateur may not
be able to make all the joints perfectly and in the perfect positions
without having all the dimensions and distances spelled out. Often, a
measured drawing requires the craftsman to build a prototype to
understand the piece and then a second to make one perfect enough to
provide the measurements.
The problem with the idea of using a programming language designed to
describe finished programs is that programs are just like poems. Paul
Valery wrote, "a poem is never finished, only abandoned." Developers
begin work on a project and deliver it when it seems to work well
enough they abandon it, at least temporarily. And hence the series of
released versions: 1.0, 1.1, 1.5, 1.6, 2.0, 2.05, etc. Trying to
write a program in manuscript using a finished-program programming
language would be like trying to write a poem using a Linotype
machine. Perhaps using a Linotype machine and thereby producing a
beautiful printed book of poetry is good for readers, critics, and
therefore literature, but it doesn't help poets and would make their
writing lives intolerable with lousy poetry the result.
The screwed-up way we approach software development is because of
what we have done with programming languages. With some exceptions,
we have opted for optimizing the description of programs for
compilers, computers, and casual human readers over providing
programming media. Early on, computers were insanely slow, and so
performance was the key characteristic of a system, and performance
was easiest to achieve when the language required you to "pin down
decisions early on." Because of this, much work was poured into
defining such languages and producing excellent compilers for them.
Eventually, some of these languages won out over ones more suitable
for drafting and exploration both in the commercial world and in
academia, and as a result it is politically difficult if not
impossible to use these so-called "very dynamic" languages for
serious programming and system building.
Interestingly, the results of this optimization are well-described by
Hoare's Dictum, often mistakenly attributed to Donald Knuth, which
states:
Premature optimization is the root of all evil in programming.
C. A. R. Hoare
Professor Sir C. A. R. Hoare was referring to the practice of
worrying about performance of an algorithm before worrying about
correctness, but the dictum can be taken to refer to any design
problem where optimization is an eventual concern. In this case, the
design problem was to design a usable programming medium that excels
at enabling developers and designers to explore and discover, and to
continue to enable discovery and exploration once well into the
perfecting stage. Instead of waiting until we understood the
ramifications of large system design and implementation using
computer programming media, we decided to prematurely optimize for
performance and optimization. And we got program description (or
programming) languages instead the root of all evil.
We can tell this analysis is correct by observing the current fad of
Agile methodologies including Extreme Programming. These
methodologies all emphasize practices in which code is delivered
early in order to enable exploring the design space in the presence
of the forces generated by the system itself. As the process
continues, the system grows and matures in the context of both
internal (system-derived) and external forces.
And we can tell that program description languages have taken the
field by observing that very dynamic languages like Smalltalk and
Lisp have faded into the background.
[Break2]
Lisp is a medium for working with a computation until it is in
balance with its external and internal requirements. At that point it
can be decorated with performance-enhancing declarations and perhaps
additionally modularized. In this it is more like an artist's medium
than what many think of as a programming language.
Lisp, viewed this way, is a good vehicle for understanding how
programming and software development really take place. Because
programming Lisp is more like writing than like describing
algorithms, it fits with how people work better than the
alternatives. The problem, of course, is that writing is considered a
"creative" activity, involving "self-expression," and creativity is a
gift while self-expression is hokey. Not so:
The conventional wisdom here is that while "craft" can be taught,
"art" remains a magical gift bestowed only by the gods. Not so.
In large measure becoming an artist consists of learning to
accept yourself, which makes your work personal, and in following
your own voice, which makes your work distinctive. Clearly these
qualities can be nurtured by others.... Even talent is rarely
distinguishable, over the long run, from perseverance and lots of
hard work.
David Bayles & Ted Orland, Art & Fear
Writing and programming are creative acts, yet we've tried to label
programming as engineering (as if engineering weren't creative).
Instead of fearing creativity, we need to embrace it.
Moreover, the key to exploratory programming is to be open to
triggers and what we happen upon, because the balance a great system
needs is not from purely external considerations. It is ok to have
been wrong in one's assumptions as long as one is willing to change
and revise. In the end one may need to become more of a guide than an
explorer, but one must always be open to being an explorer.
[Break2]
Lisp, of course, and especially Common Lisp are my languages. Not
since the 1960s have I programmed professionally in a language other
than Lisp. Sure, some of that was when I was doing AI research, but
most of it was writing system software such as the commercial
implementations of Common Lisp my company, Lucid, Inc., produced in
the 1980s and early 1990s. I worked on programming environments,
debuggers, compilers, memory managers, assemblers, and language
extensions. In many cases I was exploring what could be achieved with
the goal of productizing the results when the ideas were proved out.
Just as I explored the ideas in this essay before revising and
polishing it.
Perhaps it's the coincidence of the same mind apprehending different
things, but I used to describe AI as "trying to program what cannot
be programmed," and I currently define poetry as "trying to say what
cannot be said."
In 1995 I decided to return to school and get an Master of Fine Arts
in creative writing (poetry) at a low-residency program where most of
the work is done at home with only one 10-day residency per semester.
At that time, Lucid had been out of business for only a year, and
Lisp-based systems had been winning various software-of-the-year
awards. I had been consulting at a company that was doing a
Lisp-based product, but they were exploring other implementation
languages for business reasons.
The school I attended was Warren Wilson College, which is located in
Swannanoa in the western part of North Carolina in the Blue Ridge
Mountains. It is a small school with a world-class writing program.
One of the quaint things about the school is that it has a working
farm students are expected to work. The writing world is different
from the computing world in many ways, and soon I was immersed in
learning how to write poetry. Because I had never had a literature
background, I needed to do a lot of catching up, so I spent about 60
hours a week working on schoolwork. I was lucky to find a position as
a consultant to Bill Joy on a couple of small projects, and he
essentially subsidized me for 2 years learning to write.
When I graduated in 1998, I expected to come back to computing to
support myself, preferably by doing research. I had made my 25-year
career in Lisp, starting the Common Lisp effort, helping design CLOS,
doing research in programming environments, compilation, and parallel
languages. I thought that though Lisp might not have a great
commercial future, university and industry labs would still recognize
Lisp as a viable research vehicle.
I was shocked to learn that I was wrong. As examples, the scientific
journal Guy Steele and I founded called Lisp and Symbolic Computation
(LASC) had been renamed Higher-Order and Symbolic Computation (HOSC),
and my primary scientific conference called Lisp and Functional
Programming (L&FP) had been renamed the International Conference on
Functional Programming (ICFP). I was discouraged for two reasons. One
was that during the 1980s when functional programming researchers had
few outlets, many of us Lispers kept the lights on at L&FP for them,
and later when Lisp was on the decline, they shut the door. And the
other is that this seemed to signal that my field of inquiry had been
deleted by the academy.
Now, 5 years later, things are no better even though we face a crisis
in computing wherein we cannot build the sorts of systems we need
because we as a discipline have embraced a philosophy of
inflexibility as part of a fear of large systems when in fact the
opposite philosophy is needed. As Jaron Lanier points out, we have
not taken seriously the idea that a system or module should be
liberal in trying to accept commands or arguments, in trying to
understand what the caller wanted done. As Jon Postel remarked:
In general, an implementation must be conservative in its sending
behavior, and liberal in its receiving behavior.
Jon Postel, RFC 791
This is a statement about flexibility, about keeping a system in
balance. The perfect bridge is not perfectly rigid, nor is the
perfect building. Rigidity works when nothing moves or changes.
Flexibility is required when the ground is prone to shake or the wind
to blow. Had Web browsers required perfectly formed HTML from the
outset, there would not have been the Web. But they were designed to
encounter and deal with almost anything that came along.
Discouraged by having no computing career and lamenting static
thinking, I was originally heartened by the rising importance of XML
which amounts to some fundamental Lisp data structures reinterpreted
by people with bad taste brainwashed by inflexibility. When I
mentioned to some programmers that it might be a good idea for a
program receiving XML to use pattern recognition techniques like the
ones we used in the old AI days to try to understand what the XML was
trying to say, they scrunched their faces as if I had told them that
poetry is as true as any scientific theory.
[Break2]
I'm glad to see a new book on Lisp. I'm glad there are starting to be
some highly innovative conferences on new thinking about computing.
And finally I'm glad to see some projects that are throwing off the
shackles of inflexible programming: autonomic computing, organic
computing, phenotropic computing, acceptability-oriented computing,
and the Feyerabend project.
I believe William Stafford captured best what programming is,
especially using Lisp, when he defined art this way:
Art is a reckless encounter with whatever comes along.
William Stafford, Writing the Australian Crawl
---------------------------------------------------------------------
---------------------------------------------------------------------
+ Since I wrote this I found two other more contemporary failures
worth noting: the Millennium Bridge in London, which opened June 10,
2000 and closed on June 12, 2000 after enduring unexpected swaying
and wobbling; and the new terminal at the Charles de Gaulle airport
in Paris, whose roof collapsed on May 23^rd 2004 shortly after
opening.
The Millenium Bridge was a surprising failure given the high profile
of the project and the reputations of the designers and engineering
firms involved. Software pundits are sometimes fond of using bridge
engineering as an exemplar that software engineering should mimic.
The design of the bridge was decided by a competition organised
in 1996 by Southwark council. The winning entry was a innovative
"blade of light" effort from Arup, Foster and Partners and Sir
Anthony Caro. Due to height restrictions, and to improve the
view, the bridge's suspension design had the supporting cables
below the deck level, giving a very shallow profile. The bridge
has two river piers and is made of three main sections of 81m,
144m and 108m (North to South) with a total structure length of
325m; the aluminum deck is 4m wide.
Construction began in late 1998 with the main works beginning on
April 28, 1999 by Monberg Thorsen and McAlpine. The bridge was
completed at a cost of PS18.2m (PS2.2m over budget) and opened on
June 10, 2000 (2 months late) but unexpected lateral vibration
(resonant structural response) caused the bridge to be closed on
June 12 for modifications. The movements were produced by the
sheer numbers of pedestrians (90,000 users [[ Note the use of the
term.]] in the first day, with up to 2,000 on the bridge at any
one time). The initial small vibrations encouraged the users to
walk in synchronization with the sway, increasing the effect.
This swaying motion earned it the nickname the Wobbly Bridge.
Resonant vibrational modes have been well understood in bridge
designs following the failure of the Tacoma Narrows Bridge.
However this was the first time a bridge had displayed this type
of pedestrian excited lateral motion. As such the motion was not
anticipated by the computational analysis of the bridge prior to
construction. It is often thought that the unusually low profile
of the suspension cables contributed to the problem, but an
analysis by the structural engineer, Arup, shows that it can
occur in any suspension bridge which happens to have the
appropriate resonant frequencies. After extensive analysis, the
problem was fixed by the retrofitting of 37 fluid-viscous dampers
(energy dissipating) to control horizontal movement and 52 tuned
mass dampers (inertial) to control vertical movement. This took
from May 2001 to January 2002 and cost PS5m. After a period of
testing the bridge was successfully re-opened on February 22,
2002.
http://en.wikipedia.org/wiki/London_Millennium_Bridge
Some architectural failures are the result of a set of small design
and construction problems which combine to tragic results:
Terminal 2E, with a daring design and wide open spaces, was CDG's
newest addition. However, on 23 May 2004, not long after its
inauguration, a portion of Terminal 2's ceiling collapsed early
in the day, near Gate E50, killing four people. Terminal 2E had
been inaugurated in 2003 after some delays in construction and
was also designed by Paul Andreu. Administrative and judicial
enquiries were started. Coincidentally, Andreu had also designed
Terminal 3 at Dubai International Airport, which collapsed while
under construction on September 28, 2004.
In February 2005, the results from the administrative enquiry
were published. The experts pointed out that the there existed no
single fault, but rather a multiplicity of causes to the
collapse, in a design that had little margins of safety.
According to them, the concrete vaulted roof was not resilient
enough and had been pierced by metallic pillars; and some
openings weakened the structure. Sources close to the enquiry
also disclosed that the whole building chain had worked as close
to the limits as possible, so as to reduce costs. Paul Andreu
denounced the building companies for having not correctly
prepared the reinforced concrete.
On March 17, 2005, ADP decided to tear down and rebuild the whole
part of Terminal 2E (the "jetty") of which a section had
collapsed, at a cost of approximately EUR100 million.
http://en.wikipedia.org/wiki/Charles_de_Gaulle_International_Airport
[[In 2003 I wrote a foreword for "Successful Lisp: How to Understand
and Use Common Lisp," by David B. Lamkins. This essay is that
foreword.]]