Archive for October 2015
Adam Spitz did a presentation on Clojure in January. He made an immutable collections library, which you can find here:
I now have the bug to try to better understand functional programming. Adam mentioned a video by Rich Hickey where he makes it clear that “place” is bad.
What does that mean? What is “place”? Why is it bad? Thinking about this led me to a brain pop moment.
Rich Hickey reveres Chris Okasaki’s book “Purely Functional Data Structures.” And Okasaki disparages “destructive updates,” which are why “place” is bad. You have one location and one copy in the location, which you destroy to replace with another. Functional data structures don’t want to do that. They want “persistence,” which is copying what came before, and then changing the copy to leave the original untouched. There is no “place” where the data is.
So I started to think and my thinking became figurative and literal and odd.
A car in a numbered parking lot can be identified by the lot number, but the car still has an inherent identity. If X = 10, then X is a location that contains the number 10. But 10 has an identity regardless of the variable assignment. The car is still a car for not being in the parking lot.
The parking space is a “place.” How can a functional language access something if it has no place and no label? Where is it?
Let’s say a police station is at an intersection. You identify that specific police station by its place, by its address. Let’s say the police station now has no place. Let’s say the police station floats like a balloon above the neighbourhood. How could anybody access it? How would they know where it was? It would no longer be useful, because it could not be found or accessed.
Then I thought of a a car. (I was in a bus at the time.) A car can have no specific place. You worry if a police station has no specific place and is floating over the neighbourhood like a balloon. But you will not worry about a car. A car is supposed to move. It is not supposed to be in once place. If it’s on the highway between places, then it’s doing what it’s supposed to be doing. Moving.
And then it all collapsed into a picture in my head. In a functional program, the data is moving. You don’t worry about the “place” of a thing that is supposed to move. It’s the behavior that is staying still. Functional programs create static behavior that creates pipes that carry data forward from station to station. Questions about “place” mean nothing. If I ask “How can I access 10, if it is not assigned to X?” does not mean anything. It’s water going through a pipe. Drop a ping pong ball into clear plastic pipe and watch it go.
And so that made me realize that scope, in a functional program, is reduced to almost nothing. There is only enough scope for the data/car/water/ping pong ball to move forward. Scope in real world terms is lots and lots of space. A police station with no specific “place” can not float anywhere, because the scope of a functional program would shrink to contain it almost alone. Clojure is big on namespaces. And Rich Hickey thinks data moving over the wire though a TCP socket is an ideal. How much scope does an HTTP message have travelling over the wire? Not a lot, I don’t suppose.
You don’t need “place” in a functional language, if your scope is so constrained that there can be no confusion about the pipe your functions have created for your data to move through. Your data mutates as it travels. Persistence in the functional sense allows for continuous copying and mutation of an original datum, while leaving that datum unchanged.