The Third Bit

No explanation needed.

Uncategorized

Who do you think of when someone says, “great programmers”? Guy Steele, Brian Kernighan, Erich Gamma, and Anders Hejlsberg come to mind, but who else? Whose code do you think is particularly worth emulating?

(Yes, I have an ulterior motive for asking… stay tuned…

Uncategorized

Jennifer Campbell and I just heard that we’ve been awarded an ITCDF grant by the University of Toronto, which will let us hire a couple of student programmers over the summer to complete an online system for reviewing and grading. Very excited—it’ll be a chance to do some raaaather cool things.

Uncategorized

I’ve doing a technical review of a new book on object-oriented
analysis & design that spends several pages discussing
strongly-typed vs. freely-typed languages (using Java and Ruby as
examples). The author asserts that unit testing does for FTLs what
static type-checking does for STLs. I’ve heard this claim before—in
fact, I may even have made it myself once or twice—but the more I
think about it, the more problematic it seems.

The argument is that programmers don’t actually make type errors
very often, so requiring them to specify types all the time slows
initial development down. Yes, FTL advocates acknowledge, having
explicit types helps with maintenance and extension, but so do unit
tests. The latter are more flexible (i.e., you can check a lot more
than just variable types in unit tests), and should be written even
for strongly-typed code, so why mandate typing?

What’s missing from this, though, is any consideration of
cost-effectiveness. Which is faster: writing a dozen unit tests, or
declaring the parameter and return types of a dozen methods? Which
technique catches more errors? And crucially, which catches more
errors per minute or hour of programmer time? It’s like asking which
is more productive: two programmers writing code and tests
independently, XP-style pair programming, or having one programmer
write code while another writes tests? I think these questions can
and should be answered empirically;
I also think that the fact so many people feel it’s OK to have an
opinion one way or the other, without any data to base it on, is one
more sign that “computer science” doesn’t yet deserve the second part
of its name.

Uncategorized

Unleashed Informatics, the spin-off successor to Blueprint, has announced that it is going to enforce its patent on a “system for electronically managing, finding, and/or displaying biomolecular interactions.” Three of my 49X projects were with Blueprint—we built testing infrastructure, a SOAP interface, and a graph search engine for their flagship biomolecular interaction database—and several worked for Blueprint at various times. I’ll be interested to see how broadly they try to apply their patent, and how much good it does them.

Uncategorized

This post, titled “Why Ruby On Rails Won’t Become Mainstream”, has kicked off a lot of discussion (see, for example, Ted Leung’s response). The whole conversation is both entertaining and thought-provoking, but I was amused by point #5: “Ruby on Rails has pretty much nuked the field of Web development in Ruby, and I wonder if it’s such a good thing.” After complaining for the last year and a half about Python having so many web programming frameworks that none of them can attain critical mass, it’s rather ironic to have someone griping about the opposite…

Uncategorized

One sign of a good book is that you keep finding new things in it. A while back, I asked for help in pulling content out of mailboxes with Python. I should have checked my shelves before I posted: John Goerzen’s Foundations of PYthon Network Programming, which I reviewed for DDJ last year, had an example that was easily tweaked to do exactly what I wanted. So, thanks, John—I appreciate the help

Books

Danc has a post this morning about GameInnovation.org, a Carnegie-Mellon project to document innovations in the gaming industry. As the meta-post points out, lack of a shared language is an obstacle to high-level discussion about game design, even among experienced designers. Cataloguing what’s been done already is therefore a big step forward.

Uncategorized

The glossary for the Software Carpentry course now defines 341 terms. What may be more interesting (for those of you who have been following the course’s development) is what I’ve taken out:

• Code coverage and execution profiling: they really should be in the course, but don’t fit into any of the existing lectures.
• Date and time manipulation: it isn’t part of software engineering per se, but like Unicode, floating-point roundoff, and a dozen other things, this is one of the subjects that everybody just ought to know about. Again, it doesn’t fit neatly into any of the existing lectures.
• Cross-site scripting, and a few other security-related terms: the security lecture has been completely revamped. It’s much less ambitious, but (I hope) more informative.
• Everything to do with UML: I’ve never used it outside of class, and have only ever worked with one person who did. I therefore feel like a bit of a fraud including it in a course on practical software development.

Things that I want to add (eventually):

• Building desktop GUIs: yes, people still do this, and it’s a great way to introduce some more OO concepts. Now that there’s a book on wxPython, maybe I’ll finally do this.
• User interface design, because I agree with Catherine Letondal (who has provided some very useful feedback): you shouldn’t show someone how to build a GUI unless you show them how to build a good one.
• Numerical programming, because I agree with Tom Fairgrieve: people ought to need a license in order to use floating-point numbers. I’ve actually written this one a couple of times, but (a) Python’s Numeric module is still in flux, and (b) I don’t want to dive into this unless I have something concrete to say about how you test floating-point code.
• Extended examples: I’d like to write at least three or four mini-projects, each taking about an hour to describe, because I believe there are things you can only learn from examples.

For now, though, I’m going to concentrate on getting this release out the door…

Software Carpentry

The good news is the speaker lineup at the upcoming Mesh conference in Toronto. The bad news? Only 6 out of 50 are women. As Michelle Levesque and I observed two years ago, despite the frequency with which our community talks about “rights”, we have a lousy track record when it comes to addressing—hell, even discussing—the fact that we’re still a boy’s club.

Equity