Monday, May 26, 2008

the earliest ever "second system"?

From chapter 2 of The Code Book by Simon Singh, section "Mr. Babbage Versus the Vigenère Cipher" (page 64 in my edition):
These mathematical tables were calculated by hand, and the mistakes were simply the result of human error. This caused Babbage to exclaim, "I wish to God these calculations had been executed by steam!" This marked the beginning of an extraordinary endeavor to build a machine capable of faultlessly calculating the tables to a high degree of accuracy. In 1823 Babbage designed "Difference Engine No. 1," a magnificent calculator consisting of 25,000 precision parts, to be built with government funding. Although Babbage was a brilliant innovator, he was not a great implementer. After ten years of toil, he abandoned "Difference Engine No. 1," cooked up an entirely new design, and set to work building "Difference Engine No. 2."

Friday, May 16, 2008

the entertainment value of binary thinking

-OR- "binary thinking for fun and scant profit"

In this case, the term "binary thinking" has no relation to the nerdy timepiece you might have that befuddles less pretentious people by its lack of prosaic numerals. Binary thinking is dividing a domain into exactly two distinct sections, which may be opposites. Binary thinking uses concepts like true/false, real/fake, thesis/antithesis, good/bad, correct/borked, etc.

My point is not that binary thinking is necessarily bad and thinking in modes other than binary is necessarily good. (You see there? That would have been an example of binary thinking in action.) In a small-scale, limited, well-defined context, binary thinking is indispensable. A mathematical calculation is one of those contexts; the answer is right or wrong. A test case of an isolated computer program module is another context; the output meets the test case's check or it doesn't. More fancifully, an imaginary reality also qualifies; its events and rules are consistently presented or not.

The problem arises when someone applies binary thinking to one of the many, many practical domains that aren't small-scale, limited, and well-defined. Much of the time, two mental sections just aren't sufficiently expressive or representative to reach the best conclusion or solution. In fact, from a perspective that is unrestricted by this limitation, binary thinking can be laughable. This is the entertainment value of binary thinking, its guilty pleasure: the struggles of those trapped by it are a fine subject for schadenfreude.

Arguments between binary thinkers who speak for opposite sides kick the amusement level up a further notch. As they bicker and continue to employ the same tired rationales, spectators who don't at all acknowledge the underlying binary division can observe how each of them is right on some aspects, wrong on others, and sometimes partially right through not noticing the absurd assumption that's blocking his or her perception. Comparing the exchange to a battle between gladiators is misleading because that implies that one of them actually wins. When they steadfastly refuse to accept that the other speaks out of anything but personal bias, their own bias is unshakable.

One shouldn't start to slip, binary-thinking-style, into asserting that the titillating on-line and off-line communication skirmishes of binary thinkers are altogether useless in the productive pursuit of truth. When they do, observers learn a lot, ideally about the pros and cons of both sides. In addition, this form of conflict however "bloody" is still preferable to when people attempt to silence each other through force (and I don't mean just physical force). Binary thinking is also preferable to the even more close-minded alternative of unary thinking: complete thought conformity. Cue Winston Churchill:
Democracy is the worst form of government, except for all those other forms that have been tried from time to time.

Wednesday, May 07, 2008

a deeper reason why programmers aren't reading books

The Coding Horror blog managed once again to excite the echo chamber of software development blogs with the entry Programmers Don't Read Books - But You Should. (To paraphrase a moldy joke: when Jeff Atwood wants to screw in a lightbulb, he humbly holds it in place as the virtual world revolves around him. He's not arrogant, he just has every reason to be.) I mostly agree with him, which is unsurprising since I wrote a programming book review just a few posts ago. However, I disagree with his blanket disregard for "how" books because I have found that an up-to-date, well-organized, authoritative, understandable "how" book is better for teaching or reference than a time-consuming Web search whose results can be quite questionable. I'll certainly concede that many "how" books fail one or more of those criteria.

My slant is that the phenomenon of programmers not reading books could in some cases be a symptom of a deeper shortcoming: the illusion that busyness is equivalent to worthwhile accomplishment. This mentality is exemplified by mottos like "just do it [write code]" and "you're paid to do your job, not think". Its primary activity is scouring the Internet for example code to copy. To the extent it has an associated training regimen, the training happens at the same time as the work happens or perhaps after-the-fact. Its top goal is to produce more lines of code, not to aid the users. It has no inherent notion of a systemic approach to performance, security, exception-handling, and logging. Its style of thought is nonlinear and incoherent, i.e., absorbing ideas that may be excellent individually but nevertheless lack context and organization. Its medium of choice is the Internet (or as the old book Amusing Ourselves to Death alleges, TV). It not merely prefers prose that is broken up into little chunks, it actively rejects prose that isn't. It admittedly excels at the tasks of searching, skimming, and filtering data, yet such tasks are external to the notion that programming should proceed logically.

On the other hand, someone shouldn't respond by slipping into a false dilemma here. The Internet is a fantastic resource for programmers, especially on Web-related topics; programmers who don't cultivate a collection of browser bookmarks are missing out, as are those who don't communicate with the rest. The Internet is an excellent way to keep one's knowledge current, although it's naive to assume that Web trends are necessarily indicative of actual software development trends, which shift direction slowly like a huge ship. The narrow focus that typifies the Internet complements the comprehensive context that a book provides. And the distinction between the two can be murky. I've read online tutorials that are effectively unprinted books (or true unprinted books like Dive Into Python), and I've used some "quick-reference" books whose entries are so terse that I had to supplement the information with an Internet lookup.

Programmers should have the patience (prudence, really) to learn and ponder the entirety and meaning what they do. They should be mindful. Good books aid in that. The work of programmers shouldn't fit the metaphor for life from Macbeth:
Life's but a walking shadow, a poor player
That struts and frets his hour upon the stage
And then is heard no more: it is a tale
Told by an idiot, full of sound and fury,
Signifying nothing.