Of course, I watched the new Two Towers trailer today, just like every other Tolkien fan. And I really like what I saw.

But I noticed something I’ve noticed before, in trailers and in the full-length films. The title sequences jitter on the screen as though they were filmed by a guy sitting in a theater with a camcorder. (OK, maybe it’s not that bad, but it’s noticeable.)

Effects groups can do motion-controlled shots with live action, miniatures, matte paintings, and CG elements all merged on screen, moving seamlessly together. (For that matter, there was a translucent overlay at the bottom of the frame throughout the trailer, and it was rock solid.) Why can’t they generate title sequences the same way?

Saturday I was sitting in a talk next to PragDave, and had to boot my PowerBook (for some reason it had shut down instead of going to sleep after my talk). I took the opportunity to show him one of my favorite silly OSX features. When you type the wrong password into the login panel, it doesn’t give you a message or anything. Instead, the login panel just shakes rapidly from side to side, as though your Mac is vehemently shaking its head at you.

Dave was most amused. :-)

I’ve found a little pet project to work on. It’s an itch of my own that I want to scratch, but I can’t predict how much time I’ll have to devote to it over the long term, so my best bet is open source: release early, release often, and get other developers interested in helping.

After sitting around discussing the idea Friday night in the sitting room of the suite at RMSS, I started playing with ideas on Saturday, using Cocoa. With an example at hand, I wrote the world’s most rudimentary version of one component I’ll need: a simple line-drawing editor. So far it’s been quite easy.

Last night, in about 30 minutes, I duplicated in Java what I’d already done in Cocoa. (I’m not trying to make a point about productivity in Java vs. Objective C … I’m a Java expert who’s just learning Cocoa, and I had already written the app once, so the second try was bound to be faster.) The Java version is cleaner in some ways than the Cocoa version, but messier in others. The Cocoa version is slightly faster, but you have to get a lot of elements in the drawing before you notice a slowdown even in the Java version (and my repaint strategy in both versions is incredibly naive, so there’s a lot of room for optimization). In short: in terms of performance and ease of development, neither Java nor Cocoa seems to offer a compelling advantage. Even memory management is a wash: Cocoa will probably deliver better perceived performance due to the lack of GC pauses, but at the cost of increased development and debugging headaches.

So my thoughts are moving toward platform popularity. I don’t particularly care how widely used the app becomes; it’s my own itch, after all. But I am interested in attracting developers to help. For that purpose, Java seems like the best choice.

For a while, at least, I’ll continue developing these two versions side-by-side. But before long, I’ll have to make a choice. And right now I’m leaning toward Java.

I’m here at the Rocky Mountain Software Symposium in Denver. Both mornings, I’ve ended up showering in ankle-deep water because the drain in the bathtub was closed when I got in the shower, and I didn’t notice right away. How annoying.

So now I’m downstairs waiting for lunch with Mike, and we’re talking about weblogs. I just showed him NetNewsWire, and used James’ blog as an example. And to my great amusement, James added a blog entry today: Why Do Hotels Close the Drains?

There are very few really good books about general computer science and programming. There are plenty of good books about particular languages, platforms, or techniques, but few on the fundamentals. And most of those good general books are written for experienced programmers (for example, The Pragmatic Programmer). One of the really big problems with our whole industry is that introductory books—the books we use to teach new programmers—are so poor.

Three or four years ago I read Structure and Interpretation of Computer Programs (SICP) by Abelson and Sussman, and was really impressed. But it moves very quickly, and I don’t think many college freshmen could keep up.

Just in the past two or three weeks I’ve learned about two exciting books. I haven’t done more than skim them, but the first impressions are really strong. The first is How to Design Programs (HtDP), by Felleisen, Findler, Flatt, and Krishnamurthi. Here’s the first paragraph from the back cover (emphasis mine):

This introduction to programming places computer science in the core of a liberal arts education. Unlike other introductory books, it focuses on the program design process. This approach fosters a variety of skills—critical reading, analytical thinking, creative synthesis, and attention to detail—that are important for everyone, not just future computer programmers. We’ve needed a book like that for a long time. Like SICP, HtDP uses Scheme as its teaching language, and it manages to be a fairly general, practical introduction while grounding students in a language and concepts that should ease the transition to more advanced topics. (Unlike most introductory texts which leave students stuck in concrete, procedural thinking.)

The other book I’ve learned about is Concepts, Techniques, and Models of Computer Programming, by Peter Van Roy and Seif Haridi. Like SICP, it is aimed at future programmers and computer scientists. But like HtDP, it has a broader scope in both primary and secondary subject matter: it presents a more general view of computer science than SICP, and its examples aren’t so focused on electrical engineering problems. This book uses Oz as its teaching language, but also includes good discussion of other languages. (And Oz is a multiparadigm language, so the choice of Oz is not restrictive.) The book is very long, and likely to be longer before it’s finally published sometime next year. But I’m looking forward to reading it over the next few months.