Worlds: Controlling the Scope of Side Effects

The state of an imperative program—e.g., the values stored in global and local variables, objects’ instance variables, and arrays—changes as its statements are executed. These changes, or side effects, are visible globally: when one part of the program modifies an object, every other part that holds a reference to the same object (either directly or indirectly) is also affected. This paper introduces worlds, a language construct that reifies the notion of program state, and enables programmers to control the scope of side effects.

This paper is from the Inventing Fundamental New Computing Technologies project at the Viewpoints Research Institute (founded by Alan Kay).

Seems like it is intended to be quite a coarse-grained approach to program state. A little like a developer checking out a copy of a project from a version control system, making changes and either committing or reverting back.

State in Clojure

Many people come to Clojure from an imperative language and find themselves out of their element when faced with Clojure's approach to doing things, while others are coming from a more functional background and assume that once they leave Clojure's functional subset, they will be faced with the same story re: state as is found in Java. This essay intends to illuminate Clojure's approach to the problems faced by imperative and functional programs in modeling the world.

From: Values and Change - Clojure's approach to Identity and State.

Farewell Marion

A brave 10 year old boy shed a tear and said goodbye to his mother at her burial site today.

Cancer claims another victim and now her husband and two boys start a new journey together.

Apple Store Invoice Missing Labels

The AirPort Express arrived the day after ordering it though. :-)

File Management

I need to access my personal files in different locations such as home, work office or when traveling. I wish to be able to move between a number of trusted computers, rather than being tied to a specific laptop, as I like to cycle to and from work. I also don't want the hassle of running my own server at home (have done this in the past).

So my first step in solving this is to store all my files in a Distributed Version Control System. I get all the benefits of a common centralised VCS such as version history and version management between multiple machines, as well as being able to work normally when I don't have an internet connection (e.g. travelling). I have chosen Git, although Mercurial would probably be a fine choice to.

The second step is having a location for a master repository that is accessible over the internet. I could have purchased a hosted linux virtual machine, but I didn't want to deal with setting it up, security, software upgrades, etc. Git can synchronise repositories located at different points on the same file system, so I thought I would try a locally mounted, encrypted virtual file system over Amazon S3. I chose JungleDisk for this purpose.

As it is only me using these Git repositories, I only have one machine writing to the master at any one time, so I don't have to worry about concurrency issues. Secondly, whenever I clone a repository from the master, I use the --no-hardlinks option, although I am not sure if that is necessary.

In principle the ideas have worked out pretty well. I have run into some issues though. From minor to major:

• S3 has been unavailable on two occasions, when I have tried to access it in the last three months.


• Sometimes I have had errors pulling (synchronising) from the master. Recreating the local repository by cloning it again from the master has solved these issues. This may also be similar to the next one.


• I have had a case where I don't get any errors pulling from the master, but I don't get the latest commits pushed from another machine either. This one has been a real pain. In the process of getting everything back to a stable state, I updated to Git 1.6.0, JungleDisk 2.10a, deleted my local JungleDisk caches and reduced the cache size down to the minimum (I would have liked to turn caching off altogether). I suspect the JungleDisk caching was the issue, but that is only a guess. Will see how things go over the next few weeks.

I now don't need backups from a file deletion point of view, as the VCS takes care of that (I am not using any of the Git feature to modify history). I also keep a subset of the machines synchronised on a daily basis, so I don't need backups from a hardware failure/lost/stolen perspective either.

Introduction To Scala Training Course

Workingmouse is running an Introduction To Scala training course from Tuesday 2nd September to Thursday 4th September. The course will be run in an interactive, "hands-on" format, with a small number of people, ideally between 4 and 8.

The course covers topics including:

• Scala syntax


• A brief introduction to the essence of Functional Programming


• Algebraic Data Types and Pattern Matching


• Closures and Higher-Order Functions


• Integration with Java


• Intermediate Functional Programming topics (if time permits)

Scoodi and Me on TV

Well last week I made my TV debut, not that being on TV is something I aspire to. The subject was Scoodi and the show was Brisbane Extra.



I thought I would clarify some of the things that were said though.

First of all, I am not the brains behind Scoodi. That honour would go to Pete, who engaged us to develop the site. During that process I decided that I liked the purpose of Scoodi and thought it had potential, so became more involved.

The filming/interviewing felt pretty awkward and contrived to me. The TV crew were good guys who were trying to make things relaxed, but I wouldn't normally say things like: "You've got council pickup, garage sales and now you've got Scoodi" and "it beats a trip to the tip". Those lines seemed a pretty corny at the time.

Overall though, I was pleasantly surprised at how well the segment turned out. I was even more surprised at the amount of people that visited the site and signed up. I really hope they find it useful.