Lambda the Ultimate

Neal Stephenson is a professional writer. He started his insightful keynote with an observation that programmers and professional writers have a lot in common. In particular, both groups build complex mental structures, which they must serialize through a keyboard by pressing one key at a time.

A good writer (and a good programmer) does not work by distilling good ideas from a large pool of bad and good ones, but by producing few if any bad ideas in the first place. It is important to give ideas time to mature [in the subconsciousness] so only good ideas percolate to the conscious level.

The gist of his talk was an argument against a defined _methodology_ of writing (where 'methodology' is to be understood as in 'software development methodology' or in the Capability Maturity Model CMM). A good novel should be written mostly right the first time. A good novel is written mainly subconsciously, with the great involvement of emotion. Neal Stephenson is a great fan of Antonio Damasio. He quoted extensively from Damasio's book "Descartes' error" [see however, a critique of Damasio in http://www.cogsci.soton.ac.uk/~harnad/Tp/bookrev.htm]

At the beginning of his talk, Neal Stephenson noted that it was 20 years ago, almost to-date, that he signed his first contract and became a professional writer. He told an interesting and amusing story of writing his first book. It was a hot summer in Iowa City. Neal Stephenson had a regular job, and yet had a hunch that writing might be for him. He had written a "query" -- a plot summary, the outline of a book, biographies of characters, and a few sample chapters -- and started to send them to editors, which he picked at random from trade directories. Many rejection letters followed. Finally, one editor wrote that he was intrigued by the outline and the sample chapter and asked for the rest of the novel. After a brief exhilaration the reality set in: there was no novel yet. He had to write it. With all his vacation time and the 4th of July holiday there were 10 days, in which to write a novel. He rented a modern typewriter, secluded himself in his apartment and started to type. Soon a problem appeared: the typewriter had a modern plastic ribbon. The plastic mellowed and became sticky: it was July in Iowa City, and the apartment was hot. The only way to prevent the ribbon from getting stuck is to keep the ribbon moving. And the only way to keep the ribbon moving is to keep pressing the keys. That discovery did wonders for his productivity. He didn't have time to think: he had to keep pressing the keys and write the first thing that came into his mind. He sent thus created manuscript to the editor. The latter replied that his publishing house can't print that -- but the work was interesting and should be published. Eventually, Neal Stephenson got an agent, a publisher, and his first published book, "The Big U".

And so Neal Stephenson has become professional writer, and started to think about his next book. He wanted to follow some system of writing a book, so at least he could tell himself that he's not a slacker but a diligent worker. He picked a "distillation theory". The theory states that to write a book you start with a big draft. You keep re-writing -- distilling -- it until you remove bad parts and bring the draft to the size of a novel. The process is similar to making good whiskey out of large quantities of bad beer. Neal Stephenson spent a year working on a huge draft. When he started to distill it, he made a grim discovery. The good stuff in the draft was so intertwined with large quantities of bad stuff that it was impossible to separate them. He panicked and quickly wrote a new novel, which was published with little editing -- partly because it was written of the right size the first time. He found the process: do it right the first time. He also found that he tends to write good stuff in the morning and bad stuff in the afternoon. So he adopted the following regimen: he would write only in the morning. And to fill the rest of the day, he would help a friend as a construction worker. Surprisingly, that worked well. The construction work provided the "background" for subconscious work, where ideas were born. Some of these ideas would bubble to the conscious surface by the morning, and he would write them down.

Neal Stephenson has discovered another remarkably helpful technique: a fountain pen. The great advantage of the pen is that it is _slow_. Ideas, in his view, come faster than we can "serialize" them on the paper or at the keyboard. Therefore, the ideas are stored in an "accumulation buffer" in the brain. When in the buffer, the ideas interact and purify. If we empty the buffer too soon, we don't give the ideas enough time to mature and we get a half-baked prose. There is a virtue in slow typing or in hand-writing. Needless to say, Neil is not a fan of a PowerPoint. He contends that writing on a blackboard gives a teacher and a student so important time to think.

Neil Stephenson gave a few more examples for his thesis. For instance, many stories of Charles Dickens were first published in a magazine, over a course of several months. It is not often emphasized that Dickens didn't have time to distill his novels and to write draft after draft. He had to write in monthly installments, with barely a time for one draft. He had to do it right the first time.

One member of the audience observed that in software development, the distillation theory is called "the process". That theory states that given a number of average or bad programmers, after many iterations, good code can be produced. Just as everybody can be a writer if they merely get patience and diligence to write enough drafts. The reality of book writing and of software development shows the falsity of these views. Not everybody can be a good writer. Bad writers always write bad prose. Bad programmers always write bad code.

The message of the talk is also against debugging. It's all too prevalent for programmers to quickly type in the code they don't quite understand and aren't sure of correctness, and then debug it away. Again, the experience (e.g., with ftp clients and Sun's tooltalk daemon) shows that the code badly written the first time remains buggy and filled with holes, no matter how much it is debugged.

For example: writing a large chunk of code, then going over it to make it compile, then going over it to make it work. Writing a program, then throwing it away and rewriting it from scratch, again and again until it looks "right". Figuring out what to do, and then carefully doing it so that it's mostly right the first time. The "piecemeal growth" approach of starting with a trivial working program, and then growing it bit by bit until it does what's needed.

So many different styles, and all used to write good programs.

I've been on the piecemeal-growth style for some years now, and it works well for me. But I really must experiment with some more styles some day -- I'm particularly taken with the idea of writing a decent-ish size program, then throwing it away and rewriting it, over and over until it's really good.A friend experimented with that style recently, after the accidental deletion of some source code. He said it worked out great!

Though I have written code in the ways described ( let the problem percolate in my mind, then spew code in one zen swoop, or throw out the old and start from scratch using what I've learned the first time ), I'm not 100% comfortable with the implied prescriptive element in the talk.

There seem to be as many writing methodologies as programming ones, and I don't think any one guarantees success. Some seem to support creativity for some people better than others, but nothing more.

But this is USENIX so:
"In general, it is safe and legal to kill your children and their children" POSIX Prg Gt, by Donald Lewine, O'Reilly & Associates, 1991, p.110 (On process termination)

My intuitive feeling is that it sure does. Some languages encourage you to play with ideas (e.g., so-called dynamic languages, interpreted languages, etc.). Some languages have the opposite effect: it is impossible to provide even the simplest functionality without tons of declerations, modules and set up code (think about the famous 'professional' "Hello World" program).

I think differently in different languages. In those rare cases where thinking and programming are related, this tends to influence the way I write code...

A good writer (and a good programmer) does not...
Statements of universal truth sound so much more... definite ;-)

So many different styles / many writing methodologies
Yes, so many different kinds of writing, and so many different kinds of programming.

What kinds of writing involve multiple authors? What kinds of writing are revised significantly and republished over the course of a decade? What kinds of writing are revised and republished by someone other than the original authors? What kinds or writing have a purpose other than artistic expression?

Although programmer as novelist (individualist romantic-hero) is flattering, programmer as textbook co-author may be a better fit.

It seems that any language tends to develop an implicit theory of what it is most likely to be used for and how it will be used through a combination of semantic/syntactic design, bundled functionality, and sociological forces.

In particular, these correspond to language primitives, standard libraries and common idioms respectively.

By the choice of these, some problems and solutions find readier expression in one language than another.

I think this affects thinking in exactly the way implied by the old saying: "Give someone a hammer and every problem starts to look like a nail."

Some languages encourage you to play with ideas (e.g., so-called dynamic languages, interpreted languages, etc.).

I'm curious to hear what mechanisms you think they have that accomplish this. Is it only in the negative, i.e. they don't "make" you a bunch of things that get in the way?

It may also be worth considering that "playing with ideas" is itself a problem domain that might have special requirements distinct from (and possibly in conflict with) those of solving practical problems, such as building an enterprise application. It might nice to find one language that does both well, but I suspect there would be trade-offs there.

How about type inference, built in useful data types (e.g., maps), and incremental develop. facilities as examples?

I can see what you mean about the other two, but how do you think type inference helps to play with ideas?

My experience with SML was that it was more of a reality check on type-logical confusion than an aid to experimentation. ;-)

In fact, I tend to get the code mostly right the first time, and I spend much more time organizing the text so that it explains the code better. This seems to tie in closely with the way writers work. I even end up referring to a dictionary often.

-K

It's called Elit. I've got it as plain source, or the postscript output of running it on itself in colour or black and white.

It's based on the program presentation style from Guy Steele's RABBIT thesis. When I shoved it in his face on a mailing list he said it was "pretty cute", which (sadly!) is probably the highlight of my career. ;-)

Reading a writer's newsgroup like rec.arts.sf.composition, you see at least as much diversity as Luke was describing; what's important is to find a process that works for you, yourself. In my own hacking I'm big on distillation, not that it's quite how Stephenson described it (as filtered through Oleg). To support that I want a language where code transformations are simple and the distilled result isn't encumbered by red tape.

Ehud, you should know better than to use the meaningless phrase "interpreted language". Intrepreted or compiled is a property of an implementation, not a specification.

I think this affects thinking in exactly the way implied by the old saying: "Give someone a hammer and every problem starts to look like a nail."

There is a small flaw with this analogy (hammers and programming languages, nails and problems).

A hammer is a tool designed for a specific purpose, but within its domain a programming language is a universal tool. By definition, a programming language is Turing-complete. And let me hastily explain by what I mean with "within its domain" lest you complain about such a qualified sort of universality. Any programming language can be used to solve any computable problem: that is its domain. But you cannot use a programming language to knit a shirt.

Of course, I don't deny some languages are better than others at certain tasks. I would be the last one to make such a claim. :)

My experience with SML was that it was more of a reality check on type-logical confusion than an aid to experimentation. ;-)

What did you find confusing about it? I should think a categorial linguistics enthusiast would be quite, er, enthused about (by? over?) it.

It's called Elit.

I quite like that, the simplicity of it. Would be a tad nicer if more than one chunk could appear on a page when it and its counterpart both fitted.

I was so waiting for this...

We are in 100% agreement on that. However, the hammer is not the language but the things that are made easy in the language through a combination of its primitives, its standard library and its common idioms, and possibly other factors such as what people in its community are known for doing with it.

What did you find confusing about it? I should think a categorial linguistics enthusiast would be quite, er, enthused about (by? over?) it

In my personal history, the implication actually runs the other way. I wasn't trained in CG in school. When/where I did my degree, anything that wasn't Chomsky was "on the wrong track", so we didn't get exposed to much of it.

I came to SML knowing C/C++ (and thus thinking I understood types) and knowing Scheme (and thus thinking I understood functional programming) and discovering that it was a wee bit trickier than that. ;-)

SML got me into category theory, which made me re-examine CG. Even then it took me a long time to feel that CG might be "true", and I think in part it is the fact that I've "grokked" type-logical thinking that makes it now seem more plausible.

Actually there are a couple of potential threads here: one related to "how I got interested in PLT" and another on the relative difficulty of type-logical systems; I know you'd have something to say about the latter, Frank. ;-)

Pray tell.