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.
Labels: book, programming