The privatization of privacy

Last week I picked up Joel Bakan's The Corporation from my local library. I was interested in the premise of the movie when it came out a few years back, but never ended up seeing it.

It struck a nerve within me when Joel pointed out the continuing process of privatization that is occurring in our society. It has become a slow trend that more and more pieces of the public sector are being turned over to private management. Joel identifies the prevailing idea that a private, profit driven organization will utilize limited resources more efficiently than a public organization as one of the driving factors behind this trend.

What I find most alarming about Joel's account is the way that services which were all commonly believed to be truly public in nature, are slowly being privatized: in the US the privatization of education is well under way; in Canada, we are seeing the beginnings of the privatization of healthcare; (other examples?).

Around the same time I was reading this, I caught an interview with Jesse Hirsh on CBC radio about communications technologies such as Facebook, LinkedIn and Skype. The story was that for the first time ever, social networking had surpassed email in terms of percentage of internet traffic. At one point the host asked Jesse what this means, and Jesse responded that for him it is really the loss of private space to the public.

I thought about this for a bit, but I think there is a more subtle point than that. What we're really looking at is the privatization of privacy, as Bakan might put it. We are handing over the management of our private lives to private corporations.

It is hard to feel comfortable about this when put into those terms.

Particularly when you consider the progression of such communications technologies. At first cell phones were a luxury, but each new generation views them more as a necessity. A similar thing is happening with social networking sites. Initially they are a curiosity, but as time goes on and the networks expand, they are increasingly viewed as an integral part of how one interacts with one's peers.

On most days I feel like the concerns about social networking and the loss of privacy is an overreaction to a temporary condition as we learn how to best use these new communications mediums. But sometimes its worth it to stop and think about the "big picture" to at least understand how our lives are changing, even if we do decide its for a net gain.

State mutators

I have been experimenting with the hip, cool, Clojure language recently. Today I stumbled upon a pattern that may be useful to others.

This is a variant on the idea of memoizing function calls. The assumption there is that if the function is pure (i.e. no side effects), then we can cache the return value for a given set of arguments, and in so doing, never have to compute the function for the same argument(s) twice. Subsequent invocations of the function with the same arguments that have been computed before becomes a simple table lookup.

But what about if your function's sole purpose is to effect a state change? Well, if the emitted state change is pure, and by that I mean that the state change effected by your function depends solely on the argument(s) to your function, then you can cache the arguments of the last invocation to your function and only emit the state change when the argument(s) change.

We are using a Lisp, so let's wrap this in a macro:

(defmacro defstatefn
  "Defines a side-effecting function with cached argument.
   When called, the body is executed only if the arguments 
   differ from the previous invocation."
  [name & fdecl]

  `(let [state# (atom nil)]
     (defn ~name [& args#]
       (let [f# (fn ~@fdecl)]
         (if (not= (deref state#) args#)
           (do
             (apply f# args#)
             (swap! state# (constantly args#))))))))

The idea is that we define a function which closes over a state atom and only executes the body (side-effect) if the value of the state atom is different from the previous invocation. If the cost of the state change dominates the function call, then we will save ourself some CPU time.

I came up with this idea while pondering how to minimize OpenGL state changes when rendering a complex scene. Using this primitive, we can create some wrappers around the OpenGL state mutators and be sure that if the state we are requesting is already current, we won't do it twice:

(defstatefn gl-clear-color [c]
  (println "Calling .glClearColor")
  (.glClearColor *gl* (c 0) (c 1) (c 2) (c 3)))

Upon closer inspection, these are loafers

After thinking about this some more, I am pretty convinced that any reasonable quality OpenGL driver (in other words, any OpenGL driver that anyone would care to use) would likely be doing this for me already, so I doubt this is really useful in this context.

We are only eliminating redundant state changes from reaching the OpenGL API, whereas what I really need to do is sort my data such that a minimum number of state changes are needed to correctly render the scene.

Ah well, perhaps this pattern may be useful in other contexts.

I created this blog some time ago. I still haven't really decided whether or not I want it.