(Visiting the doctor is good for you. Today, I visited a cardiologist to make sure that my recent hospital visit was Really No Big Deal. Thus, I missed the last bus to work and worked from home today. Thus, I'm not trapped in this evening's huge peninsula traffic jam. Three cheers for modern medicine. What? Oh, right, some more chapters from Beautiful Code.)

A Spoonful of Sewage / Bryan Cantrill

Thread scheduling algorithms. When I hear that I'm going to have to think about a thread scheduling algorithm--especially a thread scheduling algorithm that isn't quite working--I gulp nervously and tug at my collar. This essay about thread scheduling algorithms; it desribes a bumpy ride. I learned from it.

Oh, I keep looking for things to quote from this essay--but things from the middle don't make much sense unless you've read the beginning. There's some talk about debugging multi-threaded problems... Oh, just go read it. Oh, here's a bit that makes some sense:

The essence of the problem is this: for user-level locks, we normally keep track of the state associated with the lock (e.g., whether or not there's a waiter) at user level--that information is considered purely advisory by the kernel. (There are several situations in which the waiters can't be trusted, and the kernel knows not to trust it in those situations.)

To implement priority inheritance for user-level locks, however, one must become much more precise about ownership; the ownership must be tracked the same way we track ownership for kernel-level synchronization primitives. That is, when we're doing the complicated thread lock dance in turnstile_interlock(), we can't be doing loads from user-level memory to determine ownership. The nasty implication of this is that the kernel-level state tracking the ownership of the user-level lock must itself be protected by a lock, and that (in-kernel) lock must itself implement priority inheritance to avoid a potential inversion.

It also has some implicit good advice for code reviewers towards the end.

Distributed Programming with MapReduce / Jeff Dean & Sanjay Ghemawat

I skipped this chapter. Hey, give me a break. I hear about this stuff all the frickin' time.

Beautiful Concurrency / Simon Peyton-Jones

People who work with Haskell keep telling me how self-documenting the code is. They never convince me--probably because they make the mistake of showing me some Haskell code. This essay didn't convince me, either. Maybe because it showed me some Haskell code and then rushed along, thinking I'd understand it.

nTimes :: Int -> IO () -> IO ()
nTimes 0 do_this = return ()
nTimes n do_this = do { do_this; n_times (n-1) do_this }

Erlang folks also pull this kind of no-for-loops nonsense, but they don't keep telling me I should be able to read it by instinct. What does a loop have to do with IO? Does IO mean what it usually means? Do I care anymore?

Jones just wrote this essay. It's not his fault that other Haskell fans have soured me on the language. Maybe I should give this essay another chance. Nnnergh. I just don't have the willpower, not today.

Syntactic Abstraction / R. Kent Dybvig

I can't blame this one on the language. I thought I understood Scheme before I read this essay. But it turns out I don't know as much as I thought I did. Or I know the wrong dialect. Or something. Yoy. And this chapter was giving me freshman software engineering class Metacircular Evaluator flashbacks. I gave up on this chapter partway through.

Another Level of Indirection / Diomidis Spinellis

I'm not exactly sure what I was supposed to get out of this essay. "Function pointers can be useful."? OK, the point of these essays was not to instruct me; the point was that people would write about beautiful code. Still, I keep hoping to learn things.

Update: I got an email from someone claiming to be Diomidis Spinellis:

My point was that layering abstractions is an elegant design that can bring about powerful synergies. Obviously I didn't make it too clear. Pointers are just a mechanism for implementing this policy.

Cheers,

Diomidis

Python's Dictionary Implementation / Andrew Kuchling

Because Python uses dictionaries for just about everything, it has some interesting use cases. I liked the Special Accommodations section here; I also liked the discussion of the Free List.

Multidimensional Iterators in NumPy / Travis E. Oliphant

This essay mostly lost me. It explained the problem OK, but then it started talking about the solution and the special data structures useful for that solution... and just lost me.

A Highly Reliable Enterprise System for NASA's Mars Rover Mission / Ronald Mak

"Middleware... java beans..." I'm sorry, my brain just went into emergency shutdown mode. Skipping to next chapter.

ERP5 / Regerio Atem de Carvalho and Rafael Monnerat

It's a flexible content management system. That's good, because no two people can agree on how they want their content management system to work. I didn't pay much attention to this chapter, though.

The Design of the Gene Sorter / Jim Kent

This essay is what I want to see in a book called Beautiful Code. He talks about the design. He dives into specifics of implementation. The section "Theory of Beautiful Code in the Large" touches on making code readable, and it has wisdom aplenty. "Programming is a human activity, and perhaps the resource that limits us most when programming is our human memory." If you find yourself, in the first few sections saying "I'm not going to write an OO system in plain old C; I'm skipping the rest of this essay," maybe instead you want to skip ahead to this essay's "Theory of Beautiful Code in the Large", which is pretty generally applicable.

How Elegant Code Evolves with Hardware / Jack Dongarra and Piotr Luszczek

What I got out of this essay: math programming is arcane.

The Long-Term Benefits of Beautiful Design / Adam Kolawa

What I got out of this essay: math programming is arcane, but you can do some things to make it a little less so.

The Linux Kernel Driver Model / Greg Kroah-Hartman

I sprinted through this essay. The previous two essays had been so arcane that I'd got into the habit of skimming. By the time I had determined that this essay might be comprehensible, I had rushed through most of it. But there were some good things.

The lack of runtime checking forces the developers who are manipulating these pointers to be absolutely sure they know exactly what type of pointer they are manipulating and passing around the system. Sure, at moments, a developer really wishes that there would be some way to determine what type of struct device he is staring at, but the feeling eventually passes when the problem is properly debugged.

Is this lack of type checking good enough to be called "beautiful code"? After working with it for over five years, yes, I think it is. It keeps easy hacks from springing up within the kernel and forces everyone to be very exact in their logic, never falling back on any checks for types that might prevent bugs from happening later.

I should note here that only a relatively small number of developers--those who code up subsystems for common buses--work on these parts of the kernel, and that they are expected to develop considerable expertise; that is why no hand-holding in the form of type-checking is done here.

I'm still not sure what I think of that. "No-one else will ever need to look at this" has been an excuse for a lot of ugly code. And yet, I can't argue with their good results here.

Dave Hill posted his write-up of Hot Springs Midnight Madness 2007, which sounds like it was pretty awesome. These people are outside, at night, in the snow solving puzzles, if I'm interpreting those photos correctly. Oh man.

The MIT Mystery hunt was this last weekend, and there are some fun write-ups. Some I spotted... Gamists Tigupine + JessicaLa. Remote Mystic Fishie devjoe posts about the GC experience. An interview with one of the few student members of this year's GC. Some guy named 530nm330hz was pretty funny. There will probably be more write-ups as people recover...

In tangentially-related news, puzzler Wei-Hwa Huang appeared in Fortune magazine wearing a shirt with a collar. I'm pretty sure that means that you can put him on your start-up's board of directors; you might even be required to.

Speaking of puzzling co-workers, Curtis of Team Snout ain't my co-worker no more. When he announced he was leaving our place of work, I started to say I was sorry to hear it--but then I stopped myself and asked, "Hey, does this mean you'll have more time to write games?" He said other people asked that, too. He was cagey about answering, but I think we can bring him around, perhaps via kidnapping and brainwashing.

(I started learning Erlang a couple of weeks ago. Then I stopped. I'd started learning how to use the concurrency features. So I tried a simple program: it ran a "while true" loop in two threads--should max out both of my CPUs, right? I looked at my system stats with a top, and saw that my program was only using one CPU.

So then I gave up on Erlang.

Then I hung out with friends. One of them was pretty frustrated trying to view some HD movies he'd downloaded. The people uploading these movies use a compressed format. The compression doesn't save much space, but most people use it anyhow. But it means that when you watch the movie, the computer needs to think pretty hard to de-compress all of that data. My friend's computer can't always keep up. He's mad at people who use this compressed format. Me, I latched onto something he mentioned in passing--his machine has two CPUs; during decompression one CPU is maxed out, but the other sits idle.

I started noodling around some ideas of how you could parallelize this task, which brought me back to thinking about concurrency. OK, Erlang didn't work. C++ threading... I dunno, there's probably some library I could use that would make C++ threading less painful than banging on my fingers with hammers. But would I be able to find that library before my head exploded?

Twisted Python sounded like it was trying to solve the parallelization problem. I set up a Twisted equivalent of the two "while true" loops. It used more than one CPU! It used... about 120% of a CPU. Nice, but less than the 200% I hoped for. Ah, I was hoping that Twisted had removed Python's "global lock" that I'd heard occasional whines about, but they hadn't. But while reading about this, I learned something...

erl -smp. Erlang uses just one CPU, unless you specifically tell it to use more, by passing the -smp flag. Why isn't that the default? Good grief. Anyhow, the "Getting Started with Erlang" tutorial, which I'd been picking my way through... it didn't mention that little detail. So now I'm back to playing with Erlang. When I'm home and alert. Which isn't often. Anyhow.

What? Oh, right, this is supposed to be a Book Report, not me whining about the sad state of parallel programming for home programmers.)

Top Down Operator Precedence / Douglas Crockford

I'm not sure what Top Down Operator Precedence is, and this essay didn't tell me. It jumped right in and showed me. Too bad I didn't follow it. This essay wasn't very useful to me, except that it made me think I should go read the original paper on Top Down Operator Precedence. Maybe if this essay had included a summary of T.D.O.P., I could have remembered that bp stood for Binding Power instead of base pointer, but I gave up on this muddle.

The Quest for an Accelerated Population Count / Henry S. Warren Jr.

Bit-counting. Oh my yes. I enjoyed this essay, but I hope I don't have much excuse to use its lessons.

Secure Communication / Ashish Gulhati

The story of a project that grew over several iterations. This essay meanders plenty. It was a fun read, but at the end, I hadn't learned anything. I wish he'd chosen one tweak to this program and dove in to more detail. The "Auditing Crypt::GPG" section seems like it would be a good one to expand.

Growing Beautiful Code in BioPerl / Lincoln Stein

When I whine about programmers who write about their own code, this is the kind of thing I'm talking about. Lincoln has his act together. There's some good stuff in this essay. But there were some stretches which seemed to talk about stuff that was kinda obvious--and I am not the smartest coder on the block.

Correct, Beautiful, Fast (in That Order) / Elliotte Rusty Harold

Emerging from the previous essay, I saw that this essay was going to be about verifying correctness of XML. My yawning muscles tensed in anticipation. But this essay was good. If you're writing an XML validator in Java, a tricky bit is: "The Java Character.isLetterOrDigit and Character.isDigit methods aren't perfectly aligned with XML's definition of letters and digits." Is it worth the processing time to use your own character-checking function?

Framework for Integrated Test: Beauty through Fragility / Michael Feathers

This essay is about a simple program that could have been made much more complicated. In some ways software engineers are like "real" engineers; one of those ways is: we over-engineer things. It's easier to write about adding things to systems rather than to write about leaving them out. What did you add to the system? You can write about that. What did you leave out of the system? Well, you left out millions of things. How do you write about that? This essay is about a simple framework that left out a lot of cruft.

Beautiful Tests / Alberto Savoia

I've already been won over to the cult of unit testing; I didn't learn much from this essay.

On the Fly Code Generation for Image Processing / Charles Petzold

Back in the day, we wrote self modifying assembly code. And by "we", I mean "not me". I didn't learn much assembly until I emerged from university. And by then, self-modifying code wasn't such a great idea anymore.

In this essay, Petzold shows how to apply the lessons of assembly code to... C# virtual machine instructions. I don't know much about C#, but it was fun to read how some bit-twiddlers are applying old tricks in a new environment to good effect.

(Another episode of Iron Puzzler is coming soon. And now, on to our partial book report, Beautiful Code, chapters 2-4...)

Subversion's Delta Editor / Karl Fogel

This essay was nice. It talks about SVN's way of expressing file trees and deltas to that tree. I think I'd seen this in some lecture or other, but it had mostly leaked out of my head again; the review was welcome. Next, this chapter discusses the problem the SVN team wanted to solve, a tricky bit of API design. Then the explanation of the API: a code comment. It's a long code comment. But it's a good code comment.

"The real strength of this API, and, I suspect, of any good API, is that it guide's one thinking." Heck, any API guides your thinking. A good API leads your thinking to a better place;a bad API leads your thinking to bedlam.

The Most Beautiful Code I Never Wrote / Jon Bentley

Jon Bentley convinced me to buy this book when he presented this essay's material as a talk. It's a great talk, with twists and turns and math and the importance of measurement. Uhm, but since I'd already seen the talk, I just kinda skimmed the chapter.

Finding Things / Tim Bray

This essay left me cold. Searching Apache weblogs with a regular expression? OK. Lookups using an index done via a binary search? Sure, OK. I dunno, this "beautiful" code seemed kind of everyday to me. Maybe there were subtle insights here that I overlooked. Maybe I take this stuff too much for granted.

Beautiful Code is a book about programming well. There are 33 chapters. In each chapter, one or two big-name programmers write about "the most beautiful piece of code they knew." As you'd expect with so many authors, the result is a mixed bag. The good parts are very, very good. I'm splitting up my book report into multiple parts, as with that Cyber China book.

A Regular Expression Matcher / Brian Kernighan

In this essay, Kernighan discusses the regular expression matching program that Rob Pike wrote for their book The Practice of Programming. There's plenty to like in this essay.

He's talking about code that he did not write. Most of the better essays in this book were by programmers talking about other people's code. Programmers writing about their own code bog down in minutiae. But maybe there's a deeper reason I liked these essays in which someone looked at someone else's code. I'm trying to learn something new about programming by looking at someone else's code. Kernighan has looked at this code and been impressed, and he thinks that code will impress me. That's a good sign. When someone's writing about their own code, you don't know that you're going to learn from it.

This code was meant to be sample code. I'm a technical writer. If you're not a technical writer, then you think I write English all day. I do write English, but I also work on sample code, and that's darned hard. It should be simple, so that a newbie can understand it; correct because many people will copy-paste that code without understanding it very well. Oh, and make sure you get it correct on the very first try, because people who copy-paste that code into their programs today won't check your errata page next month.

That's why I liked the code. To find out what Kernighan likes, get the book + read the essay. I was hoping to review a few essays from the book in each book report, and I've already meandered for a few paragraphs on just one. Sigh. Hopefully I'll calm down soon, get my concision back.

Oh, and if you're a kid fresh out of school with a newly-minted Computer Science degree, go read the Practice of Programming. I swear if I'd read that book before I entered The Industry, the first ~four years would have made much more sense.

I want to check the book Ambient Findability out of the UC Berkeley library. So I looked it up in the catalog:

1.     Morville, Peter.
       Ambient findability / Peter Morville.
       Sebastopol, Calif. ; Farnham : O'Reilly, 2005.

Moffitt      QA76.9.D26.M67 2005
               MISSING

My lip-bump had a name: pyogenic granuloma. You can Google that if you enjoy gross photos. Speaking of annoyances, what about those mathematical cranks, eh?

Back in 2006, I reported that R.S.J. Reddy sent me a copy of his book in which he failed to prove that π is approximately equal to 3.146446. Alert reader Nathan Tenny suggested that I read Underwood Dudley's book Mathematical Cranks, It took me a while to get ahold of the book. (I kept hoping to check it out from the U.C. Berkeley library system. Lately, the Math library has been closed on weekends. Which might show something about the intersection between the set of Mathematicians and the set of people with Real Jobs, but let's not dwell on that.) I finally did read it, though.

It was a fun read. I guess I already learned a fair amount about crackpots back when I lurked on Usenet, back when people used to talk on Usenet. (Usenet used to be more about discussion than about warez. I think. At least the groups I hung out on were full of discussion.) So I knew the general advice:

• When a crank tells you his wrong theory, you might tell him he's wrong; you might keep quiet.
• When you point out a flaw in the crank's argument, don't be surprised if they "disprove" your statement with an argument along the lines of "layler layler layler I'm not listening!"
• Don't sic the crank on someone else; that's mean.

This book has more. It has anecdotes. It has correspondence between cranks and mathematicians who have received crankmail. It follows the development of some cranks over the years. It has stories. It has more trends to watch out for.

• If you point out the first problem in a many-problemed "proof", the crank will figure out a way to replace that first problem with a new problem--and then claim you agree with them.
• If you say "This 'proof' just doesn't hold together," the crank will say, "No-one can point out a specific problem with my proof."

I didn't follow all of this book. Some of the math was over my head. But most of it was pretty accessible. And you don't need to know math for the most part: my crank was pretty typical: "prove" something by declaring it true and waving your hands.

Reading through this book, I think I got away easy. I've received mail from one mathematical crank. If I worked at a university math department, more cranks would target me. Maybe that was this book's most encouraging message: it could have been worse. I could have received mail from someone who was enraged at the very notion of... of... of a Menger sponge. Or they could offer a "proof" of something in number theory. I never know how to disprove anything in number theory.

Every university should have a copy of this book in their library, for the sake of whatever junior professor gets the task of responding to crank mail and needs to look up that number of the form 6p+43 which is not a square number, this disproving some common crank theory. (I just made that up, but you get the idea.) And that library should be open on weekends. Please?

When people ask me what I do at work, I clam up. Most of that stuff is confidential. Like when some of us geek gamers play-tested the geek game Race for the Galaxy some evenings, we knew it was a fun game, but we were sworn to secrecy. But now it's publicly available and I can say: it's pretty fun.

Actually, I think it's been publicly available for a while. But I forgot to post about it at the time, though I meant to. Just today I realized that I never did post about it. Intentions, actions, who can tell the difference? Anyhow, fun game. You can choose which phases of the turn you want to have happen, kinda like Puerto Rico or, uhm, that one card game? With the city? That game where you can be the thief, the assassin, the wizard, the priest, the... uhm... and you're trying to buy buildings with gold pieces, and they give you gems of different colors or something?

OK, I don't have a photographic memory for every geek game I've played, but nevertheless I remember this much: I remember enjoying Race for the Galaxy. Check it out.

I don't feel so bad about all those times Susan Ross beat me at Petaluma Game Night now that she's an award-winning game designer for her game Qwirkle.

According to one election quiz, I should vote for John Edwards or Ron Paul. According to two election quizzes, I should vote for Bill Richardson. According to yet another, I should vote for Kucinich. How do I know which election quiz I should listen to? Maybe I should set up a poll. That sounds hard. Instead, how about I present a book report for "League of Extraordinary Gentlemen: Black Dossier"?

This latest graphic novel in the League of Extraordinary Gentlemen series is a framing story and then a bunch of little bits--ephemera of the League and its past incarnations. The framing story is fun. The ephemera are less so, or maybe that's my fault. I don't like the right stories; I don't know all of these stories. (Yes, I know about the excellent online annotations, and I am grateful for them. It's all very well to learn that something is a reference to Mighty Moth; if I don't care about Mighty Moth, that reference doesn't make me like the work any more.)

I'm not a fan of the H.P. Lovecraft mythos, so I didn't appreciate the Chthulhiana--not even the short Cthulhish story in the style of Wodehouse, not even the other Cthulhish short story, this one in the style of a sort of deranged Kerouac. I'm not a fan of Shakespearean comedy (probably for the same reason that future scholars will say "Thanks to years of study, I think I see why 'I can has var?' was supposed to be funny, but it doesn't really make me laugh.") So the fake Shakespearean comedy which also [I'll leave out what else happens in this bit, lest I spoil the ending] left me cold.

The further adventures of Fanny Hill as she wanders across mystical lands in other fiction of the time which I haven't heard of and which I'm not sure why I'm supposed to care about and... And is this the most self-indulgent thing that Alan Moore has ever done? Gah.

Ahem.

But the framing story is still pretty good. Wandering around in England after the fall of Big Brother, exploring a school for spies, explaining a naming scheme for rocket ships. The story of the immortal Orlando told in the form of a sort of boy's adventure comic serial, that was pretty good. Maybe... maybe this is one of those books that you want to pick up, but be ready to skim. When you start reading the, say, the fake Shakespearean comedy, if you don't like the first couple of paragraphs, skip the rest of that part. It's fine, you'll still be able to follow the story. And the story, overall, is pretty good.

It's a graphic novel about a whiny artist who hangs out in cafes and goes to parties. Occasionally, something strange happens. It's pretty; some of the banter is witty; I'm glad I read it. The plot advances slowly, but it's a fun ride.

There's more than one comic book out there called "Chiaroscuro"--no doubt this is a hazard in the comic book industry, populated as it is by artists. "Hey, let's name the book after a term of art of art." How many romance comics are titled "Two-Point Perspective"? Uhm, hmm. Now that I look, I don't find any. So much for that theory.

Darling of course I have a page in the Internet Movie Database. Some might say that it was strange that I worked on a console game for a year. But it was all worth it for that IMDb page. Darling, working on movies is so 20th century. Real stars are made in the games, the games I'm telling you. That's why I can remember Steve Meretzky's name, but not... uhm... not... uhm... that other guy. He was in that movie. With the boat? No, the other one. Anyhow.

Hmm, this page says that something called my STARmeter is down 12% since last week. I'm not sure what that means, but it can't be good. Does this mean that I will be turned away from the door of my local taqueria? Oh, just a little while ago, I didn't even know that I had an IMDb page at all... but now I feel less famous than ever. How do I boost my STARmeter? Get my agent on the phone! Get me an agent! Heck, last week I still had that nasty-looking bump on my lip. Surely I'm more photogenic now. How did my STARmeter go down?

I can't stand this uncertainty. I'll be in my trailer.