An ongoing review of Code Complete 2: part N

As it turns out, I very much enjoyed Code Complete 2. It goes into a lot more detail than some of my other favourites (The Pragmatic Programmer and The Practice of Programming come immediately to mind), much of which is probably more useful for a novice than an experienced coder, but it's all worth reading.

Tuesday November 02, 2004

10:32 AM

An Ongoing Review of Code Complete 2: Part 1

Steve McConnell likes the construction metaphor for
software development. McConnell likes it so much that he's devoted a whole chapter to explaining why it's good and why other metaphors ("Software penmanship"; "Software farming") aren't. (He says a few good things about incremental development "Software accretion" then drops the subject.) This all rubs me a bit the wrong way I'm an "agile methods" fanboy but I'm willing to chalk that up to my own youthful sense of invincibility and my lack of experience with titanic Big-Company software projects.

Most of the meat of the first four chapters is in Chapter 3: "Measure Twice, Cut Once: Upstream Prerequisites". At first reading, this chapter is a giant handwave about requirements and design. McConnell's writing for implementing programmers on large projects, so instead of telling us how to design a piece of software, he tells us what to look for in a good design. To me, it looks like he's setting up excuses for failure: he doesn't just ask for a spec, for example, he asks for reasons why other specs weren't chosen. That's reasonable among "software architects", but it's out of place when McConnell has just told the reader that, in effect, "specifying the system isn't your problem".

You might get the impression that I don't like Code Complete 2; that's not quite true. I don't like the first part of the book, but I'm keeping an open mind about the rest of it.

Sunday October 31, 2004

02:54 PM

Why call it a "closure"?

I've been thinking a bit about why closures are called closures, and not something else. It's mostly uninformed speculation actually, looking it up would be the least entertaining option but since I'm not trying to be canonical I think that's okay.

I looked to math for inspiration (closures as programming constructs basically come from Lisp, I think, which basically comes from Church's Lambda Calculus, which is rather more mathematical than the FORTRAN/RATFOR/Algol/C line of language development. Edit: I'm wrong, it seems; see btilly's comment). A set that's closed under a binary operator is one that you "can't get out of" applying the operator to any two elements of the set will always produce another element in the set. There are other definitions on MathWorld that involve calculus or topology, but they seem to express basically the same idea.

Take, for example, the set of natural numbers and the addition operation. N is closed under addition adding two nats will never give you a non-nat. More interestingly (barely), take the set {0,1} and the multiplication operation. {0,1} is closed under multiplication.

So basically, a set closure is a function, and all the data we'll ever need to evaluate that function. Hmm... that sounds familiar.

What have we here? Well, foo taken by itself is just a function. Inside foo's scope, we see reference to something called x but x isn't inside foo's scope. foo by itself isn't closed; only the combination of foo and the enclosing scope's x is closed. So, foo plus (union) x is a closure.

Now that we've started to talk about scopes and variables, we're drifting away from our simple pleasant mathematical model of closures as functions and sets: we don't care about foo's domain or codomain (which we cared about implicitly when we started talking about binary operators on sets) we care about symbol table hits and memory reads and writes. (In a language without side effects, we get a bit closer to the mathematical ideal, which is one reason why functional-programming zealots tend to make such a big deal about assignments.) So here, a "closure" is "a function, and all the memory it needs to access when it's evaluated".

Computer-language closures are also closely (heh) related to predicate-logic sentences with free variables, but I can't find any appropriate terminology so I'm not going there.:-)

Friday October 29, 2004

10:52 PM

An Ongoing Review of Code Complete 2: Part 0

So three years ago, I worked at a smallish company with an impressive bookshelf. My manager encouraged us code monkeys to spend some time reading and improving ourselves we were even given two (paid) hours a week for "research". Anyways, the bookshelf held the first edition of Code Complete, and having heard good things about it I picked it up.

I didn't like it.

I don't remember exactly why any more. I do remember that I didn't get more than a third of the way through it before setting it down and doing something else. Then I forgot about it.

Recently, though, I've seen the shiny silver second-edition on bookstore shelves, and I've noticed a few people on Perl Monks say good things about it. So, since my stock of unread software-engineering books has run dry and my bank account is unaccountably comfortable, I picked up a copy. I thought I'd write a review of it.

First impression: That's a cute dog in the cartoons.

Second impression: That's a big damn book. (And that's a bug, not a feature.) There's no way that I'll be able to write a full review of Code Complete 2 after reading the whole thing. So, my plan is to write an incremental review, starting with this journal entry.