March 16th, 2003: Rally
I sort of went to an antiwar rally on Saturday, by which I mean that it was in front of my dorm and on the way to the T stop. It was pretty neat; some of the other events on campus have featured embarassingly poor public speakers blathering away on megaphones, whereas this was mostly just friendly-looking people holding signs.
I think this church organized the event.
Granted, some of the signs were kind of dumb. No blood for oil is as annoyingly oversimplified as Bush's "domino theory".
See? Friendly!
March 14th, 2003: Programming Theory
Warning: extreme geek content.
Reading some more about the practice of programming, or maybe you could say I'm learning more about the difference between programming and software engineering. Probably the most interesting thing I've read is this article on contractual programming; now that is a good way to minimize bugs. Maybe I should learn more about Eiffel.
Then there's pair programming. Two programmers sitting at one computer sounds a little odd, and I can definitely understand why programmers would be resistant -- I can't think of anyone at Ximian who I'd imagine would be excited to try it. But, like writing unit tests and documenting, I can see how it's the sort of thing that isn't vital to the stay-up-til-4-hacking style of programming, but would work quite well for writing robust, large software. Then again, going back to Ximian, it's not a panacea. For Ximian, it's simply not possible -- the developers don't live in the same timezones. I'm not sure whether the Evolution team could start working under XP (Extreme Programming) conditions, or in general start using some more rigorous form of software development; my guess is that it would take a long time to get used to. And since no one on the team has any experience with it, it would be hard to get people to make the transition. It'd be interesting to work on an XP-style project and find out what it's actually like.
One thing that bugs me about XP is that it seems awfully managerial; I'd be willing to program in pairs, and writing unit tests actually sounds fun, but "customer stories?" I have trouble buying that. Another thing that doesn't feel all that good to me is the idea of design patterns; it just seems like a glorification of common sense when it comes to structuring software. I dunno, I could see how some people could use a handy little list of ways to approach a problem, but seems a bit superfluous to me. On the other hand, I don't know much about patterns, so I wouldn't be surprised if I were missing the point. The other thing that seems to be a lot of buzzword with little content is refactoring; again, as far as I know, it's just strategies for fixing and thinking about preexisting code. Again, maybe I'm just not familiar enough with the ideas.
Unit tests, on the other hand, I am totally down with. I completely understand why writing tests for interfaces and modules is important, and I even think it can be fun. But it feels to me like only certain classes of code are susceptible to testing well: it wouldn't be hard to write routines to exercise a block file storage class, but what about the Camel IMAP provider? How do you test that? One element, of course, is designing for testability. I'd be happy to consider hooks for testing and profiling as a standard part of the code I write. But, going back to the IMAP example, this wouldn't be enough here. I guess I'd write a harness that let me simulate sample protocol exchanges, but it would be very difficult to then look at the internal data structures and see if things were proceeding according to plan. I guess on one level, this is just another demonstration that C should have died a long time ago; I'm sure that such introspection would be easier in a more modern language.
The last thing that excites me is documentation. Really. I have this conception of how to write a manual for software that would be totally kick-ass; I just have no software to write a manual for. But it would be so fun to write something like that: introduce the interesting points of the system, some early examples, explain the theory behind which it works, add on layers of complexity as you describe the subsystems. If I had a system to write for, I'd have so much fun doing it.
One possibility is a Secret Project that I would really like to write: a new build tool, replacing not only make but also merging in the functionality of autoconf, aclocal, automake, libtool... the length of the list demonstrates what's wrong with the GNU build chain. It wouldn't be nearly as portable (no way I am writing this in C), but screw that. The current build system is just insanely rickety -- half of the build problems reported on the GNOME mailing lists are fuckups due to weird interactions of the tools. Unfortunately, all of the "Next Generation Build Tools" that I've looked at seem to have issues. In general, they fix the Recursive Make Considered Harmful issue, but fail to provide high-level structure; or they abstract most build issues, but have very simpleminded rules and can't be enhanced in any organized way. ant has build files written in XML, which is just icky; most of the other things I've peeked at don't understand configury as a vital part of the build process. jam just doesn't have a conception of extensibility; I'm convinced a build tool needs to support extension. Today, we have aclocal macros and included make fragments, but those are such lame solutions. Tom Tromey has a NGBT called build (what I would like to call my tool, if I ever write it), but that doesn't seem to be having much work done on it, and I think he wants to implement it in Python. I think a scripting langauge is too lightweight for a tool itself, and it seems to me that you really need a specialized language to describe build rules: you do need a lot of general programming tools, but the typical use cases fit a much much smaller domain of usage. It'd be harder to express the typical use cases in Python, while the greater flexibility would only become useful occasionally.
So, anyway, if I ever write my own build, it'll have an awesome manual. You just wait and see. (The first few links are from, and the discussion was inspired by, Mike Shaver's blog.)
