Patrick Collison » blog

The British media have given a lot of coverage over the past few days to remarks made by James Watson. The interview reads:

He [Watson] says that he is “inherently gloomy about the prospect of Africa” because “all our social policies are based on the fact that their intelligence is the same as ours—whereas all the testing says not really” […] He writes that “there is no firm reason to anticipate that the intellectual capacities of peoples geographically separated in their evolution should prove to have evolved identically. Our wanting to reserve equal powers of reason as some universal heritage of humanity will not be enough to make it so”.

There are strong echoes of Larry Summers’s remarks of a few years ago: in both cases, it is being pointed out that some subset of our society currently performs worse than the group as a whole (in the Summers case, there’s a gender gap in the upper echelons of science; in the Watson case, Africans do worse on tests). And in both cases, the response has been an outpouring of politically-expedient self-righteousness and scientific ignorance.

Britain’s “Skills Minister” (no less) David Lammy was quickly out of the gates: Watson’s views “were deeply offensive” and would “only provide oxygen for the BNP [a far-right British political party]”. The Science Museum was next up: “We feel Dr Watson has gone beyond the point of acceptable debate and we are, as a result, cancelling his talk.” And, perhaps belying the the notion that the British have an understanding of irony, the Bristol Festival of Ideas cancelled his invited talk.

Watson absolutely deserves strong criticism for the remark that “all the testing says not really”—because it’s not true. (The next day, he conceded that “from my point of view, there is no scientific basis for such a belief.”) But none of the responses I’ve been able to find had the confidence or honesty to disagree with Watson because he’s wrong. To simply imply that any scientist is wrong for making “offensive” remarks purely because they are offensive is vacuous.

In both the Summers and Watson cases, the issues are big. We need to figure out why the gaps in achievement exist in each case. Why can’t we have an honest debate about it?

24/10 See also: Oliver Kamm.

Giles Bowkett writes, in the context of Ruby, “debugger support is like nail-biting support, or farting-in-public support. Its absence is a feature.”

I strongly disagree. And while Giles’s stance is extreme, the perception is common. Most programmers think of the debugger as a tool they shouldn’t really need, if only they could write proper code. Even the name itself leans this way. The tool in question is one which inspects the state of a running program; to call it a “debugger” is an oddly opinionated and restrictive way of expressing its functionality.

By claiming that “debugger support is for languages that you can’t run tests against gracefully”, Giles himself falls into the trap of seeing the debugger as a mechanism for fixing code. It can certainly be used for that purpose, but it’s like seeing a web browser as a tool for reading the news.

In the simplest case, the debugger is a great way for getting a feel for the running state of a program; how it flows, and how its state varies. Using it to find bugs is a small subset of this class of uses. A more common case (for me, at least) is to use the debugger while reading code. With the debugger, you jump around the running state of the program in parallel with reading the source. You get to see the program on two axes—that on which the program is defined, and that on which the program runs.

All of the information that that can be gleaned from the debugger is of course contained within the code itself (except in disastrous cases!), but to claim that one should therefore not need the debugger is an argument which reductios very fast to absurdum—you might as well read the binary. Using the debugger makes understanding exactly how code works hugely easier and faster.

Personally, my most frequent use of the debugger is to get the program into some running state, and then start writing code in the debugger itself. (This idea will probably seem strange to some people, in the same way that not freeing your memory once did.) With the debugger, I can write code in chunks that are immediately compiled into the executing environment, and which are “tested” in the most direct manner possible—in the environment of the running code. Most of this code is part of a web application, and more often than not, it’s being written while a web request is pending. To claim that tests are an adequate replacement for this kind of use of the debugger is crazy.

To return for a moment to Giles’s claim—that debuggers are bad—I’m curious to know exactly how fully he holds this position. Would he argue that print statements and stack traces, the primordial debugging instruments that Ruby does provide, be disallowed for the same reasons that debuggers are bad? And if not, at what point do debugging tools reach the critical mass of “fart-in-public” proportions?

Lastly, and on a basic level, I think Giles is making a stronger claim than he thinks. His reasoning is apparently that “tests are a replacement for debuggers, and a superior replacement at that”. But his stated claim is that “having a debugger is a very bad thing”. Nowhere in his article does he actually argue for the stronger form. Consider two hypothetical languages, Foo and Bar. Foo is a superset of Bar, but also has feature X. Giles claims that Foo is worse than Bar. To do this, though, not only has to show that X is without any possible use, but also that it’s actively harmful.

On both of these counts, the post fails to present any kind of decent evidence.

Footnote:

The article tries to drive home the point by saying “it’s also like asking why Lisp doesn’t have design patterns.” This is (presumably) a corrupted version of Norvig’s 1998 claim that most (16 of 23) of the Gang of Four design patterns are invisible or simpler in Lisp. Given also that this was shown as part of a long presentation on design patterns in Lisp-like languages, which was created while Norvig worked at Harlequin (a major commercial user of Lisp), I don’t really know what Giles’s claim is based on.

If the statement was just referring to design patterns generally, Richard Gabriel put it well:

“Here’s another true statement about patterns: If there are no such things as patterns in the Lisp world, then there are no statements a master programmer can give as advice for junior programmers, and hence there is no difference at all between an beginning programmer and a master programmer in the Lisp world.”

It’s been a while since I’ve posted something directly programming-related, so here goes. The mailing list that resulted fom the Lightweight Language Workshops at MIT is a gold mine, and something I keep coming back to read.

A lot of the most interesting and fundamental questions in programming language design tend to be debated in echo chambers: programming communities seem naturally insular in the way that any linguistic community is. While the best hackers in any language will of course frequently debate others within their community, it’s pretty rare that interesting discussion happens across language boundaries. The LL1 list was an exception, and featured a bunch of top-notch programmers (Guy Steele, Paul Graham, Avi Bryant, Robby Findler, Shiram Krishnamurthi, Matthias Felleisen, Joe Marshall, Dan Weinreb, Olin Shivers, Scott McKay…). The ensuing traffic covers all of the interesting topics: syntax, macros, environments, typing, language design, functional programming, etc.

Some highlights:

• The Scheme mistakes thread.
• Guy Steele’s Scheme interpreter that’s sufficiently complete that it can run Kent Pitman’s “evil code”.
• An interesting discussion of the power of macros, including neat examples of their power from Steele and Noel Welsh, and rebuttal by Trevor Blackwell of most of the arguments put forward. (That nobody could come up with a powerful example of a use of macros that can’t be easily implemented in a language that lacks them is surprising, to me at least.)
• Steele: “Only later, after our discovery that actors and closures of lambda expressions were implemented by identical mechanisms did we consider extending Scheme to become a useful programming language.”
• Good discussion of file-oriented and image-oriented environments. (Scott McKay was a founder of Symbolics, and Avi Bryant is a well-known Squeak/Smalltalk hacker—Symbolics’s Genera and Squeak are still two of the most impressive programming environments ever created.)
• Questions for a language designer.
• The origin of the “HREF Considered Harmful” phrase, which (by analogy) expresses perfectly the advantage of continuation-based web frameworks. (Someone notices early on how this doesn’t immediately mix well with what-we-now-call AJAX.)
• “I don’t think I intentionally misled Yahoo (too much) on this point, but if I did it was for their own good.”—Paul Graham, on pitching obscure languages to big companies.
• Static typing: “It is merely a tradition.” “[There are] TWO different traditions.” “It is the fact that a quantity may have connections to many places in a program text that makes it valuable to document the expected invariant properties of that quantity; type is one useful kind of invariant.”
• OO flamewars.
• Steele’s candidate for the worst computer science pun in the history of the field: “It seems [functional programmers] believe in the separation of Church and state”.

“God Angrily Clarifies ‘Don’t Kill’ Rule” over at The Onion. Sometimes it’s not clear whether it’s The Onion or reality that’s satirical.

Auctomatic now allows public sign-ups. Check it out and let us know what you think.

‘Till today, I hadn’t heard of Captain Planet since I was around 7. Turns out he saved Belfast.

I often have to resorting to resetting the system clock for debugging, testing, or avoiding stupid restrictions in software. Doing so is messy, since it screws with everything else on the system. After having to do it a lot yesterday, I wrote Time Warp, which is a tiny OS X dynamic library (plus two hackish front-end scripts) that intercepts system calls to gettimeofday (upon which all of the other time-related functions are implemented).

Sample use looks something like:

./time-warp -2M cal
Which outputs a calendar for 2 months ago, or:
./app -14d /Applications/iCal.app
which runs iCal thinking that it’s two weeks ago. You can download it here. Cue joke about using it to save time.

John and I were invited by James Corbett to speak at OpenCoffee Club in Limerick tomorrow morning, where we’ll be giving a quick talk about about Auctomatic (both the business and the tech)—in case you’re at a loss as to what to do with your Thursday morning. It starts at 11am at the AbsoluteHotel.com, and you can just turn up at the door.

I think it’d be an incredible experiment to shut down Elton John for five years.

There’s a great piece on the Seedcamp site about rules:

It’s ok to break the rules. That’s what entrepreneurship is about. But don’t break more than two of them (i.e. you must meet at least 6 of the 8 rules).

“You will break the rules within our predefined boundaries!”

I wonder if breaking the 6-out-of-8 meta-rule can count as one of your two permitted broken rules?