Functional Programming and the Universe

In Lee Smolin's TED talk How science is like democracy, he describes how our understanding of space and time has evolved. He describes three stages of cosmology:

1. Aristotelian, which is hierarchical and all properties are defined with respect to that hierarchy;
2. Newtonian, where properties are all defined with respect to an eternal absolute background of space and time;
3. Quantum Theory or Relational Universe, where the universe is nothing but an ever evolving network of relationships, and all properties are about relations between subsystems.
   

Two quotes from the talk that jumped out at me:

According to Newton, space is just the way that god knows where everything is.

And this one, regarding the modern relational model of the universe:

Space is just one aspect, so there's no meaning to say absolutely where something is, there's only where it is relative to everything else that is, so we call it a relational universe.

In other words, even the physicists don't use an object-oriented model to describe objects any more.

Halloween Slideshow

As a public service, I've made a Halloween slideshow out of photos I've taken over the last year. Comprising over a hundred scary, ghoulish and horrifying images, you can set it playing on a spare monitor and be frightened all day long.

Pie Night

My friends Michael and Susan have a wonderful tradition that grew out of growing too many pumpkins.

Pie night.








They make 10-15 pies, everybody brings a pie, everybody eats pie until they can't eat no more.


And then we have pie for breakfast.

Two-dimensional zip

I've been doing battle with things like CSS recently (the W3C will be first against the wall when the revolution comes,) so it was a pleasure to run into a little Haskell puzzle and an elegant solution.

I was working with a matrix represented with a list of lists: [[a]]. I wanted to add the row and column indices to each element, giving: [[((Integer,Integer),a)]].

This isn't a pattern I remember seeing before, but it seemed simple enough, so I just hacked away. Here's my first try:

> index grid = zipWith indexrow [0..] grid
>     where indexrow rn rs = zipWith (\cn r -> ((rn,cn),r)) [0..] rs

Serviceable, but neither pretty nor general. The one dimensional case is so elegant; for any list, you can add indices with:

> index1d xs = zip [0..] xs

The zip function is simple and the infinite list of indices covers all cases. So it occurred to me I was looking for two things: a two-dimensional version of zip; and a grid of index tuples, semi-infinite in both directions.

Both turned out to be simple enough. Here's the grid of tuples using list comprehensions:

> indices2d = [[(r,c) | c <- [0..]] | r <- [0..]]

And the two-dimensional zip:

> zip2d = zipWith zip

And it's easy to reproduce the "With" version:

> zip2dWith f = zipWith (zipWith f)

So now my function looks like this:

> index2d grid = zip2d indices2d grid

or just:

> index2d' = zip2d indices2d

This version is clearer, simpler and easily generalizable to higher dimensions.

Eschewing flip

I realized recently that I've developed a small dislike of the Haskell function flip, which reverses the order of arguments of a binary function:

mod 3 5 ==> 3
flip mod 3 5 ==> 2

flip is generally used in place of a lambda expression, when constructing a specialized function:

map (\x -> mod x 17) [1..] -- with lambda
map (flip mod 17) [1..] -- with flip

Unfortunately, my brain really doesn't like that reversal. When reading any non-trivial expression using flip, I have to stop and think about which argument is now where.

I've found that I prefer sections. You need to have one of the arguments handy, but I find that's often the case:

map (`mod` 17) [1..] -- with section

I like this form better because it preserves the visual ordering of the arguments, which seems to be deeply seated in my reasoning process. Because of Haskell's flexibility with switching between prefix and infix application, it's easy for me to adopt a style to suit this preference.

Paul McCartney was in a band before Wings?

Jeremy Shaw observed today that "Haskell is moving up in the world." His evidence was that a Google search for "haddock" now puts the Haskell documentation tool third on the list.

I guess we'll know that Haskell is a complete and total success when we overhear some kid in a supermarket asking, "Haddock is a fish?"

Rewinding the Mind

Jeremy Shaw sent me this bit about a DVD rewinder. Very humorous, of course, but there's also a nice little moral about programming in there.

When I was at Linspire, we often got questions from people looking to switch to Linux for the first time: How do I defrag my disk? Where do I buy anti-virus software?

We would explain that Linux filesystems didn't need defragmenting and that the virus problem was virtually non-existent. But sometimes, there was just no reassuring them. IT people sometimes said they simply had to have virus protection software, bought and paid for, because the company had made it mandatory for all computers. We felt a little silly, but we licensed one, shipped it and then they switched.

I wonder how many people learning a functional language wondered how to allocate and deallocate memory like they did in C? Whether the answer is obvious or not depends on one's understanding of the semantics of the language. If you have a model of C semantics in your head and you're looking at Haskell code, you're predictions about what's going to happen are bound to be wrong.

All these are examples of essentially the same problem. If we can't see (or otherwise sense) how a technology works, then a change in the underlying mechanism will leave us confused because our mental models are out of date.

I tend to prefer designs that show a technology at work, such as record players as opposed to most CD or DVD players. Unfortunately, miniaturization and digitalization only make the problem worse. I suppose that's why Hollywood always has been at the forefront of computer graphics, because the audience has no idea what's going on without all the flashing lights.

I will pursue these ideas further in some upcoming posts about functional programming and user interface design.