FoxtrotUniform's Journal http://use.perl.org/~FoxtrotUniform/journal/ FoxtrotUniform's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:44:04+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 FoxtrotUniform's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~FoxtrotUniform/journal/ An ongoing review of Code Complete 2: part N http://use.perl.org/~FoxtrotUniform/journal/24863?from=rss <p>Oops, that didn't work out at all the way I'd planned.</p><p>As it turns out, I very much enjoyed <i>Code Complete 2.</i> It goes into a lot more detail than some of my other favourites (<i>The Pragmatic Programmer</i> and <i>The Practice of Programming</i> come immediately to mind), much of which is probably more useful for a novice than an experienced coder, but it's all worth reading.</p> FoxtrotUniform 2005-05-25T01:48:49+00:00 journal An Ongoing Review of Code Complete 2: Part 1 http://use.perl.org/~FoxtrotUniform/journal/21655?from=rss <p>All right, let's get this show on the road.</p><p> <i>Code Complete 2</i> is a tradesman's guide to software construction.</p><p>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.</p><p>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 <i>weren't</i> 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".</p><p>You might get the impression that I don't like <i>Code Complete 2</i>; 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.</p> FoxtrotUniform 2004-11-02T15:32:09+00:00 journal Why call it a "closure"? http://use.perl.org/~FoxtrotUniform/journal/21617?from=rss <p>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.</p><p>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. <b>Edit:</b> 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 <a href="http://mathworld.wolfram.com/">MathWorld</a> that involve calculus or topology, but they seem to express basically the same idea.</p><p>Take, for example, the set of natural numbers and the addition operation. <i> <b>N</b> </i> 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.</p><p>So basically, a set closure is a function, and all the data we'll ever need to evaluate that function. Hmm... that sounds familiar.</p><p>Now let's look at closures in computer languages, like, oh, let's say Perl. A closure in Perl looks something like this:</p><blockquote><div><p> <tt>{<br>&nbsp; my $x = 0;<br>&nbsp; sub foo { # foo is closed over $x<br>&nbsp; &nbsp; return $x++;<br>&nbsp; }<br>}</tt></p></div> </blockquote><p>What have we here? Well, <i>foo</i> taken by itself is just a function. Inside <i>foo</i>'s scope, we see reference to something called <i>x</i> but <i>x</i> isn't inside <i>foo</i>'s scope. <i>foo</i> by itself isn't closed; only the combination of <i>foo</i> and the enclosing scope's <i>x</i> is closed. So, <i>foo</i> plus (union) <i>x</i> is a closure.</p><p>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 <i>foo</i>'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".</p><p>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.<nobr> <wbr></nobr>:-)</p> FoxtrotUniform 2004-10-31T19:54:27+00:00 journal An Ongoing Review of Code Complete 2: Part 0 http://use.perl.org/~FoxtrotUniform/journal/21599?from=rss <p>Wow, a use Perl journal.</p><p>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 <i>Code Complete</i>, and having heard good things about it I picked it up.</p><p>I didn't like it.</p><p>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.</p><p>Recently, though, I've seen the shiny silver second-edition on bookstore shelves, and I've noticed a few people on <a href="http://perlmonks.org/">Perl Monks</a> 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.</p><p>First impression: That's a cute dog in the cartoons.</p><p>Second impression: That's a big damn book. (And <i>that's</i> a bug, not a feature.) There's no way that I'll be able to write a full review of <i>Code Complete 2</i> after reading the whole thing. So, my plan is to write an incremental review, starting with this journal entry.</p> FoxtrotUniform 2004-10-30T03:52:25+00:00 journal