TITLE: Technology, Speed, and Language AUTHOR: Eugene Wallingford DATE: August 23, 2004 4:29 PM DESC: languages can improve how fast and well we speak, too ----- BODY: Ryan Dixon pointed out an interesting connection between technology, speed, and language in response to one of my recent posts. Recall that Clive Stephenson had blogged on how typing changes how we write, because it lets us put more material on the page faster than writing by hand. In my recent entry, I talked about how a similar 'speed-up' technology -- agile development -- affects how we write programs and how this perhaps should affect how we teach programming. In response, Ryan sent me this quote by Paul Graham, from his wonderful On Lisp:

Imagine the kind of conversation you would have with someone so far away that there was a transmission delay of one minute. Now imagine speaking to someone in the next room. You wouldn't just have the same conversation faster, you would have a different kind of conversation. In Lisp, developing software is like speaking face-to-face. You can test code as you're writing it. And instant turnaround has just as dramatic an effect on development as it does on conversation. You don't just write the same program faster; you write a different kind of program.

This is an important insight: you would have a different kind of conversation. Notice the how the ideas of testing and continuous feedback play into Graham's comment. And notice that the synergy between the two leads not just to a difference in degree but a difference in kind. Graham obviously thinks that the change is an improvement. I do, too. I think this notion underlies the benefits of having empowering technology in your hands. It's why writers are usually better off by getting lots of material down on paper quickly: the act of making thoughts concrete in words changes the act of writing, and it gives the writer something real with which to work. It's why an agile development style can lead to good programs -- better programs!? -- even without big design upfront: the act of writing small tests and small functional bits of code change the act of programming. They also give programmers something concrete with which to work, rather than fuzzy requirements and the design abstractions they build in their head. Programmers learn from the growing program, and they can feed this learning back into the next code they write. Graham speaks specifically of Lisp, but I think he'd agree that other languages offer a similar experience. Smalltalk is one. Interactivity plays a big part in the experience, though there's also something about the kind of language one programs in buried in there, too. Some languages facilitate this style of programming more than others. Lisp and Smalltalk, with their "everything is customizable" designs, do just that. I love how seemingly little ideas can flow together to create something much bigger... -----