I found a great story from Lubomir Kavalek in his recent column, Chess Champions and Their Queens. Many years ago, Kavalek was talking with Berry Withuis, a Dutch journalist, about Rashid Nezhmedtinov, who had played two brilliant queen sacrifices in the span of five years. The conversation reminded Withuis of a question he once asked of grandmaster David Bronstein:
"Is the Queen stronger than two light pieces?"
(The bishop and knight are minor, or "light", pieces.)
The former challenger for the world title took the question seriously. "I don't know," he said. "But I will tell you later."
That evening Bronstein played a simultaneous exhibition in Amsterdam and whenever he could, he sacrificed his Queen for two minor pieces. "Now I know," he told Withuis afterwards. "The Queen is stronger."
How is that for an empirical mind? Most chessplayers would have immediately answered "yes" to Withuis's question. But Bronstein -- one of the greatest players never to be world champion and author of perhaps the best book of tournament analysis in history -- didn't know for sure. So he ran an experiment!
We should all be so curious. And humble.
I wondered for a while if Bronstein could have improved his experiment by channeling Kent Beck's Three Bears pattern. (I'm a big fan of this learning technique and mention it occasionally here, most recently last summer.) This would require him to play many games from the other side of the sacrifice as well, with a queen against his opponents' two minor pieces. Then I realized that he would have a hard time convincing any of his opponents to sacrifice their queens so readily! This may be the sort of experiment that you can only conduct from one side, though in the era of chess computers we could perhaps find, or configure, willing collaborators.
Since sometime last summer, I have been posting capsule reviews of the movies I watch on Facebook. They are reactions, really, not reviews -- three bullet points, or a couple of sentences, that express how I felt during after watching. These updates have been humorous for many of my friends, because I'm often watching movies that they watched one or five or ten years ago. As many movies I have watched, I'm still just catching up. The selections vary from old standards ("A White Christmas"), to recent classics ("American Hustle") and cult classics ("Firefly: The Series"), to guilty pleasures ("The Replacements").
A couple of months ago, Tyler Cowen blogged about choosing movies and wrote this about reading reviews before watching a movie:
I use movie criticism in the following way: I read just enough to decide if I want to see the movie, and then no more. I also try to forget what I have read. But before a second viewing of a film, I try to read as much as possible about it.
I have a similar approach on my first viewing. If I already know I want to watch a particular movie, I read nothing about it. If not, I read the bare minimum needed to make the decision. Then I do my best to forget it all. I don't want to be reminded about what I already knew about the movie or what I just read about it. I want to watch with as clean a mind as possible.
Yet I can watch certain movies many, many times and enjoy them immensely every time. Sometimes I read a lot about a movie, both background and criticism, mostly because I love pop culture and I love hearing about how creators create. However many times I watch though, I try to watch each time with a beginner's mind. This used to drive my wife crazy: "You've seen this movie a dozen times; what do you mean you don't want to think about what happens next?". One of my gifts seems to be an ability to suspend memory and belief. When watching movies, that's usually how I like it best.
What's your advice to new writers?
I first have to say that whatever moderate success I may have achieved has been so much a result of dumb luck that I feel fraudulent presuming to offer any advice to young writers, as if I did any of this on purpose or according to plan.
I appreciate humble advice.
The advice Kreider goes on to give aspiring writers is mostly obvious, as he says up front that it will be, but he also shares a quote from Thoreau that I like:
Read the best books first, or you may not have a chance to read them at all.
As someone who most days runs out of time to read as much computer science as I want, I value this reminder.
As I settle into a new semester of teaching students functional programming and programming languages, I find myself again in the role of grader of, and commenter, on code. This passage from Tobias Wolff in Paris Review interview serves as a guide for me:
Now, did [Pound] teach Eliot to write? No. But he did help him see that there were more notes to be played he was playing. That is the kind of thing I hope to do. And to counsel patience -- the beauty of patience, which is not a virtue of the young.
Students often think that learning to program is all about the correctness of their code. Correctness matters, but there's a lot more. Knowing what is possible and learning to be patient as they learn often matter more than mere correctness. For some students, it seems, those lessons must begin before more technical habits can take hold.
On the racket-users mailing list yesterday, Matthias Felleisen issued "a research challenge that is common in the Racket world":
If you are here and you see the blueprints for paradise over there, don't just build paradise. Also build the bridge from here to there.
This is one of the things I love about Racket. And I don't use even 1% of the goodness that is Racket and its ecosystem.
Over the last couple of years, I have been migrating my Programming Languages course from a Scheme subset of Racket to Racket itself. Sometimes, this is simply a matter of talking about Racket, not Scheme. Others, it means using some of the data structures, functions, and tools Racket provides rather than doing without or building our own. Occasionally, this shift requires changing something I do in class, because Racket is fussier than Scheme in some regards. That's usually a good thing, because the change makes Racket a better language for engineering big programs. In general, though, the shift goes smoothly.
Occasionally, the only challenge is a personal one. For example, I decided to use first and rest this semester when working with lists, instead of car and cdr. This should make some students' lives better. Learning a new language and a new style and new IDE all at once can be tough for students with only a couple of semesters' programming experience, and using words that mean what they say eliminates one unnecessary barrier. But, as I tweeted, I don't feel whole or entirely clean when I do so. As my college humanities prof taught me through Greek tragedies, old habits die hard, if at all.
One of my goals for the course this semester is to have the course serve as a better introduction to Racket for students who might be inclined to take advantage of its utility and power in later courses, or who simply want to enjoy working in a beautiful language. I always seem to have a few who do, but it might be nice if even more left the course thinking of Racket as a real alternative for their project work. We'll see how it goes.
Coming into the semester, I didn't have any students doing their undergraduate research under my supervision. That frees up some time each week, which is nice, but leaves my semester a bit poorer. Working with students one-on-one is one of the best parts of this job, even more so in relief against administrative duties. Working on these projects makes my weeks better, even when I don't have as much time to devote to them as I'd like.
Yesterday, a student walked in with a project that makes my semester a little busier -- and much more interesting. Last summer, he implemented some ideas on extensible effects in Haskell and has some ideas for ways to make the system more efficient.
This student knows a lot more about extensible effects and Haskell than I do, so I have some work to do just to get ready to help. I'll start with Extensible Effects: An Alternative to Monad Transformers, the paper by Oleg Kiselyov and his colleagues that introduced the idea to the wider computing community. This paper builds on work by Cartwright and Felleisen, published over twenty years ago, which I'll probably look at, too. The student has a couple of other things for me to read, which will appear in his more formal proposal this week. I expect that these papers will make my brain hurt, in the good way, and am looking forward to diving in.
In the big picture, most undergrad projects in my department are pretty minor as research goes. They are typically more D than R, with students developing something that goes beyond what they learn in any course and doing a little empirical analysis. The extensible effects project is much more ambitious. It builds on serious academic research. It works on a significant problem and proposes something new. That makes the project much more exciting for me as the supervisor.
I hope to report more later, as the semester goes on.
Good advice in this paragraph, paraphrased lightly from Modern Garbage Collection:
Garbage collection is a hard problem, really hard, one that has been studied by an army of computer scientists for decades. Be very suspicious of supposed breakthroughs that everyone else missed. They are more likely to just be strange or unusual tradeoffs in disguise, avoided by others for reasons that may only become apparent later.
It's wise always to be on the lookout for "strange or unusual tradeoffs in disguise".
In the Paris Review's The Art of Fiction No. 183, the interviewer asks Tobias Wolff how he balances writing with university teaching. Wolff figures that teaching is a pretty good deal:
When I think about the kinds of jobs I've had and the ways I've lived, and still managed to get work done--my God, teaching in a university looks like easy street. I like talking about books, and I like encountering other smart, passionate readers, and feeling the friction of their thoughts against mine. Teaching forces me to articulate what otherwise would remain inchoate in my thoughts about what I read. I find that valuable, to bring things to a boil.
That reflects how I feel, too, as someone who loves to do computer science and write programs. As a teacher, I get to talk about cool ideas every day with my students, to share what I learn as I write software, and to learn from them as they ask the questions I've stopped asking myself. And they pay me. It's a great deal, perhaps the optimal point in the sort of balance that Derek Sivers recommends.
Wolff immediately followed those sentences with a caution that also strikes close to home:
But if I teach too much it begins to weigh on me--I lose my work. I can't afford to do that anymore, so I keep a fairly light teaching schedule.
One has to balance creative work with the other parts of life that feed the work. Professors at research universities, such as Wolff at Stanford, have different points of equilibrium available to them than profs at teaching universities, where course loads are heavier and usually harder to reduce.
I only teach one course a semester, which really does help me to focus creative energies around a smaller set of ideas than a heavier load does. Of course, I also have the administrative duties of a department head. They suffocate time and energy in a much less productive way than teaching does. (That's the subject of another post.)
Why can't Wolff afford to teach too many courses anymore? I suspect the answer is time. When you reach a certain age, you realize that time is no longer an ally. There are only so many years left, and Wolff probably feels the need to write more urgently. This sensation has been seeping into my mind lately, too, though I fear perhaps a bit too slowly.
(I previously quoted Wolff from the same interview in a recent entry about writers who give advice that reminds us that there is no right way to write all programs. A lot of readers seemed to like that one.)
I'm not a New Year's resolution person, but I did make a change recently that moved me out of my comfort zone. Here's a quick version of the story.
I'm a hierarchical guy, like a lot of computer scientists, I imagine. That helps me manage a lot of complexity, but sometimes it also consumes more personal time than I'd like.
I'm also a POP mail guy. For many years, Eudora was my client of choice. A while back, I switched to Mail.app on OS X. In both, I had an elaborate filing system in which research mail was kept in a separate folder from teaching mail, which was kept in a separate folder from personal was kept in a separate folder from .... There were a dozen or so top-level folders, each having sub-folders.
Soon after I became department head a decade or so ago, I began to experience the downsides of this approach as much as the upsides. Some messages wanted to live in two folders, but I had to choose one. Even when the choice was easy, I found myself spending too many minutes each week filing away messages I would likely never think of again.
For years now, my browser- and cloud-loving friends have been extolling to me the value of leaving all my mail on the server, hitting 'archive' when I wanted to move a message out of my inbox, and then using the mail client's search feature to find messages when I need them later. I'm not likely to become a cloud email person any time soon, but the cost in time and mental energy of filing messages hierarchically finally became annoying enough that I decided to move into the search era.
January 1 was the day.
But I wasn't ready to go all the way. (Change is hard!) I'd still like to have a gross separation of personal mail from professional mail, and gross separation among email related to teaching, research, professional work, and university administration. If Mail.app had tags or labels, I might use them, but it doesn't. At this point, I have five targeted archive folders:
I still have three other small hierarchies. The first is where I keep folders for other courses I have taught or plan to teach. I like the idea of keeping course questions and materials easy to find. The second is for hot topics I am working on as department head. For instance, we are currently doing a lot of work on outcomes assessment, and it's helpful to have all those messages in a separate bin. When a topic is no longer hot, I'll transfer its messages to the department archive. The third is is a set of two or three small to-do boxes. Again, it's helpful to an organizer like me to have such messages in a separate bin so that I can find and respond to them quickly; eventually those messages will move to the appropriate flat archive.
Yes, there is still a lot going on here, but it's a big change for me. So far, so good. I've not felt any urges to create subfolders yet, and I've used search to find things when I've needed them. After I become habituated to this new way of living, perhaps I'll feel daring enough to go even flatter.
Let's not talk about folders in my file system, though. Hierarchy reigns supreme there, as it always has.