I like to learn programming by doing. After many attempts to learn Lisp by reading, I tried by doing. Much higher level of success!

The turning point was finding the online version of Practical Common Lisp. Aside from being a great book, it also includes a bundled Lisp and Emacs package called - Lispbox. This provides similar functionality to other languages, such as hugs/ghci for Haskell or the python interpreter.

A quick download for any major platform and you have a Lisp prompt waiting for you to type something useful. Start reading the book and you learn something useful to type.

Peter Seibel has done a terrific job with this book. The tone used involves the reader in the Lisp world with glimpses into the long history of Lisp. All of this with a practical approach to learning. By the end of the book, a streaming Mp3 server is possible!

Perhaps the biggest barrier to a proper understanding of macros is, ironically, that they’re so well integrated into the language.

- Chapter 8

Lisp macros have started to make sense to me (help!). Try to think of being allowed to write any C++ code to generate the expansion of a #define and having the C preprocessor know what you meant. Very, very powerful.

Why am I learning Lisp? One theory is Sapir-Whorf:

the hypothesis argues that the nature of a particular language influences the habitual thought of its speakers. Different patterns of language yield different patterns of thought.

Possibly. My main reason is that it looked fun. I’ve spent a bit of time playing with languages that owe a lot to Lisp. It made sense to have a look at Lisp and see for myself. The scary part is that I may stay a while … writing web services in Lisp is awfully tempting.

Bonus link: http://www.defmacro.org/ramblings/lisp-ducati.html - discussion as to Lisp vs Haskell and which to learn … Both!

If you are interested in the search world, Andy has a great article about the inclusion of Wikipedia results in Google’s OneBox results.

What is curious is that in determining this confidence level, Google seems to rate the title(s) of Wikipedia articles as a better indicator of relevance than their own ranking algorithms.

Worth a read.

Two interesting things turned up for me around the same time that have ended up linked. The first is the concept of using Lines of Code (LOC) to improve estimates. There are a bunch of things you can use LOC as a proxy for during the estimation process.

The second area is using LOC analysis to improve QA time spent. Microsoft has been doing a bunch of research that culminated in a paper that uses the relative change in LOC (churn) of a software project to determine the most likely place bugs will occur.

A case study performed on Windows Server 2003 indicates the validity of the relative code churn measures as early indicators of system defect density. Furthermore, our code churn metric suite is able to discriminate between fault and not fault-prone binaries with an accuracy of 89.0 percent.

The counting of LOC should be entirely possible. The analysis of that data may take a bit more fiddling, but is work that needs to be done once. It can then be built into the configuration management process for the development team. The next step is then integration of the data into a task/bug/issue tracking system to link in with estimates.

Microsoft has found a strong correlation between relative code churn and where bugs appear. Industry research backs up using LOC for estimation. Definitely an interesting thing to start experimenting with.

If I manage to stay in one place for long enough, stay tuned for my experiences with this in practice. Reality may struggle to meet my current levels of excitement, but if the results are even a small improvement I’ll be happy.

After a year of living in Brisbane, I’m returning to Melbourne and have accepted a position at my old company, Atex.

I’ve learned a lot during my time in Brisbane. Lots of randomly useful technical things, like the explicit keyword for C++ and how mobile phones are built.

More importantly, I’ve discovered a lot of things about myself. A large part why I’m going back is crystallization of my values and how they impact what I do with my time.

If only I had managed the same revelations without the hassle of moving interstate twice.

To keep things interesting I’m traveling around a bit:

• 3 - 10 Feb: In Melbourne conducting a training course for Trolltech
• 12, 13 Feb: Last days in the Brisbane office
• 14 Feb: Moving company takes my stuff
• 15 Feb: Attempt to clean enough to recover bond and then hit the road
• 16 Feb: Brief stop in Sydney
• 17 Feb: Drive to Melbourne
• 19 Feb: Commence work at Atex

I’ll be a bit out of touch while moving gets sorted out. If you need to get hold of me, my mobile is the best bet.