I just finished listening to part 1 and part 2 of Robert Lefkowitz's talk The Semasiology of Open Source.

Computer source code has words and sentence structure like actual prose or even poetry. Writing code for the computer is like writing an essay. It should be written for other people to read, understand and modify. These are some of the thoughts behind literate programming proposed by Donald Knuth. This is also one of the ideas behind Open Source.

Robert is a very entertaining speaker and manages to convey some deep insights into the nature of software and our current location on the development curve of software literacy.

Here's a short biographical sketch about Robert Lefkowitz on O'Reilly Radar.

The OCaml tutorial chapter 11 is quite interesting.

Why is OCaml fast? Indeed, step back and ask is OCaml fast? How can we make programs faster? In this chapter we'll look at what actually happens when you compile your OCaml programs down to machine code. This will help in understanding why OCaml is not just a great language for programming, but is also a very fast language indeed. And it'll help you to help the compiler write better machine code for you. It's also (I believe anyway) a good thing for programmers to have some idea of what happens between you typing ocamlopt and getting a binary you can run.

(referenced in Andrew Birkett's blog)

Andy Hertzfeld wrote an entertaining article about the discovery of Hungarian notation at Apple in 1982. Nowadays Charles Simonyi is busy selling Intentional Programming. He's come a long way.

Leo Pos pointed out an article by ESR where he analyzes the management of closed source vs. open source projects and (not surprisingly) concludes:

Our reply, then, to the traditional software development manager, is simple -- if the open-source community has really underestimated the value of conventional management, why do so many of you display contempt for your own process?

Once again the example of the open-source community sharpens this question considerably -- because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Two and a half years after the first version of this essay, the most radical thought I can offer to close with is no longer a vision of an open-source-dominated software world; that, after all, looks plausible to a lot of sober people in suits these days.

Rather, I want to suggest what may be a wider lesson about software, (and probably about every kind of creative or professional work). Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency.

Relating to your own work process with fear and loathing (even in the displaced, ironic way suggested by hanging up Dilbert cartoons) should therefore be regarded in itself as a sign that the process has failed. Joy, humor, and playfulness are indeed assets; it was not mainly for the alliteration that I wrote of "happy hordes" above, and it is no mere joke that the Linux mascot is a cuddly, neotenous penguin.

It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work.

There's some essential truth in his last sentence. Don't get me wrong. I've been there and failed (web archive link). IPmeter was Open-Source, dual licensed and came ready-to-run in a 1U box. We burned some 10m Euro until we realized, that bandwith was "to cheap to meter". Bummer.

How can we have fun coding and pay our bills at the same time? I'm still trying to find the answer.