Making coffee the Chinese way

Today, I share with you a great insight.

Do you like coffee? do you get fed up with the paraphernalia needed to make it, and washing everything up? I do. Why can’t it be as simple as tea? The fact is, you don’t need any hardware except for a cup and a teaspoon. And, you will probably use less ground coffee in the process.

How does it work? take a look at one of the traditional methods the Chinese use for tea. They just put a few leaves in hot water, and when the leaves sink, it’s ready to drink. (And you can top up with water again to make the leaves go further – most good teas are fine for this.)

Well, the same works for coffee! So try this: 2 teaspooons of coffee grounds in a normal-size mug, with milk (optional) and then top up with near-boiling water, and leave for a few minutes. Stir occasionally. After about five minutes, most of the grounds will have sunk and you can drink the coffee.

It’s not bad, is it?

Worth mentioning: the ‘Byzantine’ method (Greek coffee etc) is kind of similar – heating the coffee and water mix to boiling and then not bothering to separate them.

Why free variable?

Someone asked. Well, I wanted something just a little bit geeky, but the delightful strictly positive has already gone, and terms like ‘iota reduction’ just don’t have the same ring. Plus, ‘free variable’ seems quite apt now that I’m away from the binder of organised education! – and having much more fun too.


No, not me. Well, I think not.

I recently gave a talk to the North East’s excellent SuperMonday group on Git (with a brief intro to the main ideas behind version control). When I was working as a lecturer, it never ceased to amaze me just how few of the final year students could use any kind of VCS. Such tools are pretty essential for the large individual projects they were working on. You would not believe the numbers who still used dated folders! Even worse, the number who didn’t save versions (or backups) regularly. And some took the folders technique to an extreme, with ornate schemes (and scripts) for creating dated folders and transferring them to various places in the universe. One student claimed to have copies of his versions on a bomb-proof serrver in Surrey. Quite a few saved copies of work on their girlfriends’ machines – but not all couples were still speaking when that material was needed in an emergency…

Anyway: the key points is: we’ve got very good tools now, and they are easy to use – so you really should be using them for anything that’s remotely important. Plus, these tools are quite handy for synchronising work between different machines, so no ad hoc ftp’ing or usb stick juggling.

My preferred weapon is Git. I came straight from RCS and CVS, avoided Subversion etc, and Git to me seems pretty near perfect. Try it now!

Here’s the talk slides (in PDF). The supermondays site has a video on it too. It does look a bit gothic – the venue was a small cinema in Newcastle, and there was a lot of black around.

We’re not in Kansas anymore, Toto

Beginners in Haskell often get stuck with the design and pragmatics issues. For me, the golden rule is this: think about data structures.

By this I mean: work out what data structures you’d like to use, and think about the various ways you’d like to transform your data (e.g. from a list of words to a binary search tree to a list of sorted words). And be confident in your ideas, and don’t get derailed by worrying how exactly to do each step (you will often find that big, hard steps break into small, easy steps – just have patience). Languages like Haskell really do promote thinking in these terms, rather than the details of what gets done when and to whom etc, and I think this makes for a much more powerful way to program.

Here’s an example of thinking in data structures, rewriting a standard example in a way you might never have seen, not a div in sight – but in a way that I think is much closer to the spirit of the game/problem. I give you: Fizz Buzz.

The task is is – you want Fizz every three steps, and Buzz every five steps, and sometimes the cycles coincide. Let’s talk cycles then.

threes = cycle ["", "", "Fizz"]
fives  = cycle ["", "", "", "", "Buzz"]

where ‘cycle’ is defined like this (the real library def is more efficient, but less clear)

cycle xs = xs ++ cycle xs     -- SIMPLE version of lib

So “threes” just spits out [“”,””,”Fizz”,””,””,”Fizz”,… ] until we stop it, and similarly for “fives”. Next, we want to merge two streams into one: this is quite common so there’s a library function for it. To cut a long story short, “zipWith” pairs up elements and uses some  operation to combine each pair,

zipWith g [a,b,c,...] [d,e,f, ...]  ===> (computes to)  [g a d, g b e, g c f, ...]
zipWith max [1,2,3] [2,2,2] ===> [2,2,3]
zipWith (*) [1,2,3] [2,2,2] ===> [2,4,6]

Think zippers, of course. Now, that’s just what we want for merging our streams. It works for infinite streams too.

fizzbuzz = zipWith (++) threes fives

(++) is string concatenation, and then we just push the list of lines to the screen. And hit ^C when we get bored.

main = putStr (unlines fizzbuzz)

If we want numbers in there between the fizzes and buzzes, we can just zip in another list that contains the indices, and just add in that info if the string would otherwise be empty. Notice: still working with data structures.

So: it’s a short piece of code which obviously works, built from small pieces and glued together in a simple way, and there’s no worry about loops, division, memory limits, … I like programming like this!

Welcome to!

This site has been set up by  Paul Callaghan. I’ll probably use it to discuss various aspects of programming language technology. I like programming, and like anything that helps me do complex things more elegantly and precisely. So expect to see something about Haskell, Ruby, and dependent types in the coming weeks. You’ll also see something about interesting algorithms and how to express them in a flexible language. Stay tuned!