I'm psyched: A good friend of mine living in another state just sent me a signed copy of William Gibson's book, Pattern Recognition. The inscription reads "For Sir Isaac: Don't unleash any AI into a network you can't power down; wm gibson" This reference to AI is presumably wrt my job. I've been reading a copy of this book that I got from the library so as to preserve this signed one (that I knew was coming eventually). He also sent me a really minimalist wristwatch that looks like a hairtie. I like it. It's very light and loose fitting, low-profile and probably not highly valuable, so I can use it during while rock climbing and stuff.

The Monad Reader is a monthly newsletter by Haskellers. From the announcement email: This month's issue has a definite introductory theme. It includes republished book reviews, notes on learning, a look at the differences between functional and object oriented programming, and distributed computation. As always, The Monad.Reader invites submissions on Haskell and related topics. Send a summary or abstract for your article to shae@ScannedInAvian.com -- Shae Matijs Erisson

Over the last few years, I've been pretty immersed in the world of wikis. A wiki is like a collaborative web site; it lets several people view and edit a web page and link to other pages, maybe new pages that they themselves create. Wikis let tech-savvy people all over the world collaborate on a single web page, a single document. That's a pretty powerful idea, really. The obvious thing to do once an idea like wikis appears is to attempt to cram all of humanity's knowledge into it. Well that's just crazy enough to work. Wikipedia is the gold standard of wikis. It's a collaborative encyclopedia with lots and lots of articles. As the gold standard, it influences people's thinking about wikis in ways that might not be quite true. If Wikipedia were the only wiki you'd ever heard of, you might think that wikis are used to create encyclopedias. If that were true, you'd really only need one of them. If Wikipedia were the only wiki you'd ever heard of, you might be under the false impression that all wikis everywhere are editable by anyone. So if you create a wiki page, it's no longer yours. Other people can scribble on it. Well, some kinds of documents perhaps just aren't suitable for being edited by anyone, and the good news is that you can build a wiki for you and your classmates, or you and your coworkers, and you can decide who gets to edit what. I want to think about a few distinct uses for wikis in different contexts. The most common use is of course to create a knowledge repository; a collection of information written by people who know what they're talking about. That's what Wikipedia is, mostly. That's what the Haskell Prime wiki (which I run) is. And the excellent wiki about the game of Go, Sensei's Library, is also a knowledge repository. But there are other uses for wikis that are pretty cool. I often have to work on proposals with my coworkers. One (horrible) way to do this is to write the first draft in MS Word, email it to everyone, who might edit it and email it back. Of course, only one person can actually edit it at a time, otherwise I have to figure out what everyone did and merge their changes by hand. That's what we, in the computer industry, call teh suck. A better way to do this is to use a version control system, which lets multiple people work on a document at one time. Of course, if you're editing evil document formats like Word, still only one person can edit it at a time, but at least you cut out email, so things are a bit better organized. But wikis are actually a really great way to work on a document with another person. Two or more people can each collaborate on the document using the wiki software over the web. What becomes of the document at that point depends on its ultimate use. Maybe you have to convert it to MS Word or PDF at the end. That's a bit of a bummer. So there are two uses of wikis that I've mentioned: building a knowledge repository, and collaborative writing. Google started a service for collaborating on documents called Google Docs & Spreadsheets, which is probably useful for collaborative writing, but not knowledge repositories. They also acquired a wiki startup a few days ago, so they are clearly trying to get all over this space. There's another very interesting use of wikis that I'll call situation awareness. You can get a really vivid picture of this use of wikis if you take a look at the wikipedia article on the July 2005 London bombings. By the way, I didn't discover this excellent example of situation awareness using wikis. I saw it in the slides for a talk, but I don't know the original source at this point. If you go to that link, you'll see an excellent and up-to-date encyclopedia article about the London bombings. It's not a news article. Go to Google News and try to find a news article from a major news source which is this detailed, up-to-date, and well organized. Most articles you'll find are a snapshot, taken at a particular point in time (when the article was published) that most likely contains an account of the latest developments, and usually brief background in case you missed previous stories. The wikipedia article isn't a snapshot, it's an article that explains things in a logical order, which isn't necessarily chronological. Each wikipedia article contains a link to its own history. You can look back over time and see the article evolve. If you look at the early edit history of that London bombing article, you'll notice something fascinating. The article was created shortly after the bombing, with an account of the information that was known at that time. Within an hour, many people had edited the article, adding information they know about. If you were refreshing that wikipedia entry over & over (or if you were subscribed to it using RSS), you'd see not an account of just the latest developments, but an evolving, logical understanding of the attacks. The article started evolving right away, and it continues to evolve to this moment. That's what I'm calling situation awareness. Don't get me wrong, the mainstream news media is quite good at situation awareness. They do it a bit differently, and their articles or TV stories don't become integrated into a knowledge repository like wikipedia. I've enumerated three somewhat overlapping uses for wikis that I think are pretty interesting to examine:

Knowledge Repositories, which are a lot like encyclopedias,

Collaborative writing, which is a bit like a more elegant version of emailing word documents, and

Situation awareness, which isn't so different from the news; it draws from the news as a source, it can also be authored by the eye-witnesses themselves, and each story becomes an integral part of a knowledge repository. I don't claim that these are an exhaustive, nor are they a partition: Wikis are also used for bug tracking and as web discussion forums, for instance. What other categories can you think of? Email me if you have ideas.

I really enjoy the book The Pragmatic Programmer. One of the suggestions in this book is to learn one new programming language every year. Since the new year is upon us, I though I'd suggest that this year, everyone should learn Haskell. So please apt-get install hugs, grab Yet Another Haskell Tutorial, and get hacking. You'll probably want to have the Libraries API bookmarked. You might want to install the Glasgow Haskell Compiler after a couple of hours. When you get ready to package your first Haskell library for Debian, be sure to check out the state of the Haskell Cabal (the Common Architecture for Building Applications and Libraries). Here's a basic implementation of cat in Haskell. Compile With: ghc Cat.hs -o myCat

import System
main = do a <- getArgs
          contents <- sequence (map readFile a)
          putStrLn (concat contents)

I'd be very happy if folks email me with suggestions on what programming language, API, technique, paradigm, or whatever I should learn this year. You definitely get extra points if you can give me a link to a good tutorial and if an implementation of the language is packaged for Debian.

The latest terrible story about a voting machine is here. In summary: 19,000 registered voters, 5,352 ballots cast, 144,000 votes counted by the machine. Does anyone remember the bug in Intel chips that came out something like 10 years ago? It looked (at least at first) like it would only affect a few people under very rare circumstances, but the media totally freaked out and Intel was forced to fix the problem (as well they should). Have we become so numb to bad software that we don't care when the machines we are using to help decide elections have such awful bugs in them? Does anyone notice when the bugs aren't so terribly obvious (negative votes, 138,000 delta from actual votes to counted votes).

The idea of breaking programs into functions was taught to some of us with the metaphor of "divide and conquer." That is, make several smaller problems and solve those instead. This approach is now so deeply ingrained that I can just think "partition and solve" which is of course a much more positive and accurate description. One might think of the "partition your program into functions" principal as "the divide and conquer" principal. But of course, they are both instance of the more general "partition and solve". I dare say that "partition your program into functions" is even a more pure and accurate instance of the principal. Evolution may also be an instance of the principal. Different species evolved to solve different problems, or to solve the same problem (survival) in different ways. Of course, when you partition a program into functions, you also define those functions' relationships to each-other. Just because you're partitioning doesn't mean that the problems are not related. When people see several competing projects in the "free software community" trying to solve the same problem, some might say, "Good. We have divided them, now we will conquer them!" In their marketing material (or more likely press-release ranting) they will say that a house divided against itself will not stand [1]. Such people are probably purposefully ignoring the "partition and solve" principal. They ignore the fact that different projects have chosen different paths to solve different problems. They ignore the relationships between the projects, and that we feed each-other much more often than we actually compete. But no good programmer will ignore the relationships between her functions. Even within the Debian project we have lots of different goals. A truly gifted project leader will hopefully not see Debian as a house divided, but rather a very ripe partitioning looking for someone to define the problem that we solve together. A leader should help to define, create, or encourage the relationships that make that solution happen. peace,
isaac
[1] Oh no, I've contradicted the Bible and praised evolution in the same essay! Well, not really. The fallacy is not with the Bible's assertion about the house divided against itself, it's in the interpretation of "the free software community" as a single house. And also, I believe God created evolution :)

I've been on a Sci-Fi kick. I just finished reading The Dispossessed by Ursula K. Le Guin. I've read a few of her books before, but I really liked this one a lot. It reminded me a of some of Daniel Quinn's ideas. I picked it up sorta randomly because I'd read a couple of her books before. I had it sitting on my desk at work, and a few people said, "Oh, you're reading that? That's one of the best books I've ever read". Of course, I got it used for $3.50 at Powell's. I wonder how they get away with reprinting such books for $15. One interesting aspect of the book is that one of the languages used doesn't really express possessives. So instead of saying, "my book" it was always rendered as "the book". I didn't really notice this until near the end. When I did notice it, was when Le Guin wrote, "the mother" instead of "his mother". This didn't seem quite right to me, because it doesn't represent the relationship between "him" and "mother", but it's not really Le Guin's fault... there's no convenient way to represent this in English without using the possessive form. Perhaps "the mother of the man," but that still seems a bit possessive. I believe this is also true of Russian and Spanish at least. One way to look at it is that humans are so focused on possession that we don't have a convenient way to express relationships. But we are certainly not saying, "The mother that I own." Another way to look at it is that the so-called possessive case expresses more than just possession. In fact, it sometimes means possession and sometimes not. If my mother fell off her horse and I had to rush back to Ohio to visit her, and someone asked me why I was going, I might say, "Because she's my mother!" Not possessive. But clearly, it is sometimes possessive, particularly in romantic relationships. Jealousy is possible in all forms of relationships, but is probably most clear in romantic ones. "Why did you go to the prom with him when you're MY girlfriend?" This reminded me of the "object" formulation in object-oriented programming languages. (Didn't know that I was going to say THAT, did you? Ha!) In a language like Java, you say something like "the car's first wheel's last screw", "car.wheel[0].screw[3]". In Haskell, you also have aggregate types, where one type is composed of others but to access them, instead of saying, "the car's wheel" we say, "there's a relationship between cars and wheels. It doesn't matter what the relationship is, but the function from cars to wheels is called "wheels". So we have "last $ screws $ first $ wheels car". That is, "the last screw of the first wheel of the car"... actually that's clearer than "the car's first wheel's last screw" isn't it? There we go. I've once again proven that Haskell is morally and technically superior to C++. Randomness Here is an article linked from Slashdot about how people are giving up on the internet because of spam and spyware. The article doesn't mention GNU/Linux or Firefox. I just took one of those quizes that you've all been doing, and I was pretty disappointed.

I think someone should volunteer to set up "Planet Haskell" or "Functional Planet" (which would include other languages) ala Planet Debian, Planet Gnome, Planet Lisp (which is made with secret alien technology), Planet Perl, etc. These sites are "Blog aggregators". Basically they just collect the RSS feeds of the community and post their blogs to a web page in a cute format (the gnome one is especially cute, but you probably could have guessed that). There are already sites like The Haskell Sequence and Lambda the Ultimate which have a similar purpose, though not quite the same. There's already software out there for this, so nothing new needs to be written. I think we need a volunteer to set this up somewhere? Preferably someone with their own server, and we'll worry about setting up the DNS later :)

I'm pleased to report that my review of the Haskell School of Expression: Learning Functional Programming through Multimedia just got published on Slashdot. As I point out in the review, it's not a new book, but still very relevant.

The recent goal for Haskell' has been to actually start committing modifications to the Haskell98 report. Well, as mentioned on the mailing list, we've started making changes relating to Pattern Guards. The current draft of the Haskell' report will be auto-generated whenever someone submits a patch. Thanks for setting up the build system, Malcolm! Haskell' ("Haskell Prime") is the working name of the next Haskell language standard. Haskell is the best programming language in the world.

I want a cell phone that runs Linux. I've been wanting one for a long time. Why should I care what OS it runs? Well, I have two main reasons: 1) because I want to support commercial ventures related to free software, and 2) I want to write applications for it, and I don't want to be beholden to some vendor to sell me a development kit, and tell me what I can and cannot write. I want to apt-get install the developer kit, write some code, and upload it to the phone. Rock. I've been paying only scant attention to the cell phone market since I got a Treo 600, which I like a lot. It is _not_ a Linux-based phone. It runs PalmOS, which is a pretty crufty OS, but I've been using it since 2001, so I have a lot of data in there. It should be pretty easy to get the data out, though, so I'm not worried. I really like the Treo's thumb-keyboard; It's qwerty, and I can type pretty fast on it. Numeric keypad based phones are lame. I hardly ever type in numbers anyway. Apple recently announced the iPhone, which I shouldn't even mention because it doesn't allow 3rd party applications, doesn't run on a free operating system, and is probably very buggy since they've never done anything like that before. Enough about Apple. As I poke around the intern-webs, I find that some stuff has been happening over the year when it comes to Linux-based phones, but I'm having a hard time figuring out exactly what is happening. It's surprising how little information is out there. Despite this great list of starting places from linuxdevices.com, the rabbit trail never leads to a "buy this phone" button. Look! There's an open Linux-based phone platform called OpenMoko. At least, I think that's what I pieced together from the scant information available on their web site. Maybe OpenMoko is the phone and openembedded is the platform? I had a very nice conversation with some folks on freenode who explained a bit about this really cool project to me. It looks like they even have a phone that it sounds like is going to be released soon, and it's discussed on LinuxDevices.com. That phone looks pretty sweet. It has a GPS built in too. I like the touch-screen idea that I guess it has, based on the pictures, and it's not way too expensive. Maybe that's the phone I'll get. All it's missing is a "buy it now" button. Oh, and "apt-cache search openmoko" doesn't turn up anything. So on to the Green Phone by Trooktech. This looks pretty good, but not as a replacement for my Treo, since the primary interface is a numeric keypad instead of a qwerty keyboard. It looks like you can actually buy a development version of the phone, but it's not overly free; you cannot develop commercial applications on it without paying them a licensing fee. Lamers. According to some folks on freenode, this phone is just a prototype for vendors like this one. (But do you see a "buy this phone" button on that page?) There's a nice article that talks about several of these devices, including the Nokia N800, which is a Linux-based handheld computer / web appliance. I played with one the other day, and it's pretty sweet. Too bad it isn't a phone, or I'd buy one today. So it looks like there's no open, Linux-based, qwerty phone out there yet. If you know otherwise, let me know. Perhaps one is coming out next month. I think I can wait that long.

Say the word "infrastructure" and you conjure up the images of paved roads, hot water, and that series of tubes that makes up the Internet. In other words, infrastructure is that necessary stuff that lets you get your job done, but it doesn't seem sexy. Every open source project needs a high-quality infrastructure, though, and it turns out that building infrastructure is extremely fun, even though it's not as sexy as building "the next killer app". I've spent a lot of time building software infrastructure. The Debian project is (mostly) not about building new applications. It's about brining together projects with a solid infrastructure so that real people can use it. The Haskell Cabal is a piece of infrastructure that helps other people to compile and distribute applications. So what makes building software infrastructure seem less fun, even though it's really great? It's the idea of measuring the results of your work indirectly. It's easy to say that we wrote n lines of code this year, or that "my application" has n users. Depending on the size of n, that might make us feel good, or feel bad. But measuring results indirectly is much harder. You have to be content to say things like, "I helped 10 programmers build 15 applications for 5000 users, but I only helped each one a little bit." That's an indirect result. But if you are more interested in the result than in who creates it, then you're in a good position to let yourself have fun building infrastructure. If you are more interested in fun than in glory, then you're in a good position to get fulfillment in life :) In fact, infrastructure is really fun to build, at least in computing. You get to take a series of tubes and put them together in a new way. You get to lay the groundwork for many projects that come behind you. There's a bit of systems administration, a bit of hacking, and a lot of contact with the your peers in the community. People will help you figure out what to build since they're chasing right behind you using your stuff (at least in the open source world). People will respect and even occasionally thank you for helping them to do their job. Of course, some pieces of infrastructure become sexy. Debian's apt-get is considered pretty darn cool among those in the know. Writing awesome compilers that real people use (like GHC or Cryptol) is the dream of a lot of computing science academics. The Internet itself is actually cool these days, or so I hear. The Haskell language and community is badly in need of infrastructure right now. We need people to flesh out and improve the existing debuggers, code coverage tools, and IDE support. We need a robust package database, sysadmin support, and project repositories. We need folks to make Debian and Gentoo packages from Haskell packages. If you like people, and want people to get to know you and to appreciate your work, then go out there and discover an important piece of infrastructure that people need. Ask them what exactly they want, how they would build it, but be sure to bring your own vision to the project as well. Most of all, have fun building something with your friends.

I'm excited because we're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. Let's imagine something that would be awesome for the Haskell community. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 was just released, and I think we should try to make this happen. Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other. I just created an empty directory "testing". I propose that we start testing packages, starting with the Cabal release that'll went into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work. So what will we need for this to happen?

An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot?

Some initial set of packages (maybe just cabal-install) to start off.

Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this.

The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing".

A web interface (lemmih is working on it)

A script to upload packages to "unstable" (Paolo is working on it).

Someone to spearhead all of this! We need volunteers. Please email me if you think you can head this up.

let haskell' = succ haskell98 in
Announcing the Haskell' ("Haskell-Prime") process.  A short time ago,
I asked for volunteers to help with the next Haskell standard.  A
brave group has spoken up, and we've organized ourselves into a
committee in order to coordinate the community's work.  It will be the
committee's task to bring together the very best ideas and work of the
broader community in an "open-source" way, and to fill in any gaps in
order to make Haskell' as coherent and elegant as Haskell 98.
Our task is broadly defined by our mission statement:
    The Haskell programming language is more-or-less divided into two
    "branches".  The Haskell 98 standard is the "stable" branch of the
    language, and that has been a big success.  A lot of progress has been
    made over the last few years in the "research" branch of the Haskell
    language.  It is constantly advancing, and we feel that it is time for
    a new standard which reflects those advancements.
    Haskell' will be a conservative refinement of Haskell 98. It will
    be the work of this committee to adopt a set of language
    extensions and modifications and to standardize a new set of
    libraries.
    We will strive to only include tried-and-true language features,
    and to define them at least as rigorously as Haskell 98 was
    defined. This standard will reflect the realities of developing
    practical applications in the Haskell language. We will work closely
    with the rest of the Haskell community to create this standard.
Your Haskell' Committee is as follows (slightly munged email addresses
follow):
 * Manuel M T Chakravarty <chak at cse.unsw.edu.au>
 * John Goerzen <jgoerzen at complete.org>
 * Bastiaan Heeren <bastiaan at cs.uu.nl>
 * Isaac Jones <ijones at galois.com>
 * John Launchbury <john at galois.com>
 * Andres Loeh <loeh at iai.uni-bonn.de>
 * Simon Marlow <simonmar at microsoft.com>
 * John Meacham <john at repetae.net>
 * Ravi Nanavati <ravi at bluespec.com>
 * Henrik Nilsson <nhn at cs.nott.ac.uk>
 * Ross Paterson <ross at soi.city.ac.uk>
 * Simon Peyton-Jones <simonpj at microsoft.com>
 * Don Stewart <dons at cse.unsw.edu.au>
 * Audrey Tang <autrijus at gmail.com>
 * Simon J. Thompson <S.J.Thompson at kent.ac.uk>
 * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk>
 * Stephanie Weirich <sweirich at cis.upenn.edu>
The editors are Isaac Jones and John Launchbury.
Feel free to contact any of us with any concerns or questions.  If you
don't know who to direct your questions to, email Isaac Jones
ijones at syntaxpolice.org.
Community involvement is vital to our task, and there will be a way
for members of the community to make formal proposals.  In the opening
phases, please use these more informal resources to help us coordinate
Haskell':
 * The haskell-prime mailing list.  All technical discussion will take
   place here, or (if other meetings take place) be reported here.  Anyone
   can subscribe, and any subscriber can post questions and comments,
   and participate in discussions.  Anyone can read the list archives.
   http://haskell.org/mailman/listinfo/haskell-prime
 * A wiki / issue tracking system to document consensus and to track
   ongoing tasks.  This system is publicly readable, but only
   committee writable so that we may present it as the "official"
   output of the committee.  If you ever feel that the wiki is not
   accurate as to the consensus, please alert the committee!
   http://hackage.haskell.org/trac/haskell-prime
 * A darcs code repository for experiments, proposed libraries,and
   complex examples.  darcs is a decentralized system, so anyone can use
   it, but patches should be sent to Isaac Jones:
   http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode
Please join us in making Haskell' a success.

I'm very exited this week because the company I work for just released a piece of open source software, Halfs, a Haskell Filesystem. There are a few groups thinking of using it, including darcs, a revision control system, and house an operating system written in Haskell. Since it requires kernel modules and a very specific Linux kernel (for now), I decided to release a virtual machine image that folks can download and just use on any architecture as described in the "virtualization environment" section of the quick start guide.

I'll try to update the Haskell community periodically on the status of the Haskell' language standard. As mentioned previously, we are currently focusing on two topics, concurrency and the class system. If you feel that you have anything important to contribute to those topics, now is the time to review the proposals, join in the Haskell' mailing list and let us know what you know! Stephanie Weirich has posted a summary of the class system discussion. Stephanie says:

     This page is important because it lists all of the proposals not
     related to MPTCs as well as trying to capture the big picture
     about where we stand with respect to MPTCs. I've been trying to
     not duplicate text that appears elsewhere in the wiki, but just
     provide a consistent picture of the state of the discussions on
     the mailing list.
     Please take a look at this page and help me fill it out. In
     particular, I've been trying to take a pulse of where we stand on
     some of these issues, and some of you may not agree! Tell me if
     I'm off the wall. Also, I've (mostly) concentrated on issues that
     have tickets, so I may have missed some issues that were only
     discussed in the mailing list.  Please let me know if there is
     anything I've forgotten.

Simon Marlow has posted a summary of the concurrency discussion. Simon says:

     I have tried to summarise the various points that have arisen
     during the discussion.  If anyone feels they have been
     mis-paraphrased, or I have forgotten something, please feel free
     to edit, or send me some text for inclusion.  I don't want to
     include long gobs of text in here, though: just summarise the
     main points, and if necessary link to relevant mailing list
     posts.

Thanks, Simon & Stephanie for keeping things moving forward!

Greetings! You may know that ICFP 2006 will be in Portland, OR where I live. I'm wondering who will be there. If you know / have met me / chat w/ me on IRC, please drop me a line and let me know you'll be in town. peace.

The following are my own opinions and impressions: It seems that California is taking action against Diebold, who has been working hard to break democracy in the US by selling broken hardware and software meant for voting. An advisory panel to Secretary of State Kevin Shelly recommended that California should ban the use of some 15,000 machines. This is really good news. One has to wonder that with no paper trail, and the number of screw-ups we know about already, how many more screw-ups were there? And on the SCO front, it seems that one of their major investors wants their money back. SCO has been trying to make money by suing people involved in Linux, including IBM. This might make it a little hard to pursue aggressive (and in my opinion, unethical) legal avenues against Linux users and vendors.

I was somewhat curious what the Haskell code for Lars Wirzenius experimental language benchmarks would look like. So I put together a quick implementation of it. It's 69 lines with a lot of comments, 34 lines without comments or type signatures (his Python implementation is 57 lines with a few comments). No, I don't think number of lines is an argument for quality. I wasn't programming for number of lines, by the way, this code is very readable to any Haskell programmer. Try it with the GHC compiler, especially with optimization. It should also work just fine with the Hugs interpreter (using runhugs). Note that this doesn't really address the speed issues that Lars is interested in. I don't know what input he's using anyway. You might want to read the GHC manual about how to write sooner, faster, smaller, thriftier Haskell code. Of course, I think that Haskell is a wonderful language both for serious programming, and for hobbies. Maybe it's the new programming language you should learn this year.

I've been busy with various things at work and at home. Hopefully if all works out well, you'll see something I wrote last week here soon. I'm very pleased that the darcs package has entered Debian unstable and builds on most platforms, after some tweaking. Darcs is an advanced revision control system. I'm pretty excited about it, and have started using it to track changes in my packages. It would be so wonderful if every upstream author used a distributed system like darcs or arch, since I could cherry-pick changes from the unstable branch to apply to the stable branch (if the author didn't do so themselves). For instance, I reported build problems in the darcs package on PowerPC, the upstream author fixed it in HEAD, I used "darcs get" to pick out the change I wanted, applied it to the stable version, and voila. This leads to a discussion I'm having with some Haskell developers about using version control systems other than CVS for certain projects. There's some resistance to it, even though darcs is written in Haskell, though the momentum isn't really a bad thing. I just wish that everyone were as excited as me about version control. For something so critical, caution is definitely called for, but I hope we can phase-in newer systems. So yeah, a bit of hacking on the Haskell Library Infrastructure Project, mostly behind the scenes working on making hmake into an API suitable for our purposes. Ohio LinuxFest got some Slashdot coverage. Cool!