-- Rich Hickey
Rich starts by mentioning that this is not a Clojure-specific talk until the very end. What we'll have is, in essence, a philosophical talk about programming practices followed by a practical application of these in Clojure
"Pure" functions: depend only on their arguments, given the same arguments, always returns the same value, has no effect on the rest of the world, has no notion of time. Rich wants to reduce the definition of a function to what is essentially a mathematical one.
To the extent that you write functions as he just described, you will write better programs - easier to test, safer, cleaner. But in large respect, most programs are not functions and do not consist of a majority of functions. For the purposes of this talk, Rich defines anything that is not a pure function as a process.
A process may include the notion of time. They may have effects on the outside world, might produce different answers at different times even given the same arguments (for example, a search engine).
"Variables in traditional languages are predicated on a single thread of control, one timeline." Of course, as soon as you add concurrency you introduce problems. Your variables are no longer atomic, they may require locks, they may require workarounds to deal with the problem of time.
It behooves each language to have a model for Time. Something must be built into the language to check if one event happens before, after, or at the same time as some other event. In fact, relativity is what we are really after with respect with time.
I'm wavering here. Last session and I'm getting a little bombarded by the philosophical discussion. I needed to hear this earlier in the day. Good thing I'm going to the Clojure Pragmatic Studio and learn more!
Example: Race-walker foul detector. If left and right foot are off the ground at the same time, that is a foul. This is another demonstration of how time must be taken into account. We need a snapshot of the world at a particular time in order to make this decision. We also can't solve this problem with locking (in this real world example, this would mean stopping the runner to inspect his foot position). If we had a value that included time, I could solve this problem.
Core to Programming Approach
- Programming with values is critical
- manage the succession of values (states) by eschewing changing values in place
Using Persistent Data Structures
- Immutable composite values are the key. Change is thereby merely another function that takes one value and returns another. The value is immutable so we don't have to worry about change outside the world of the function.
- The collection maintains its performance. It does not degrade as the program is developed further.
Rich has a way of instilling confidence in you, the developer, when implementing functional programming languages, particularly his own. His message: "Don't worry about threads, don't worry about state, don't worry about concurrency gotchas. I'm worrying about all of that for you so that you don't have to." That makes me feel nice, and like I need to spend more time exploring Clojure than I have already.
That talk got pretty mind-blowing toward the end. I was talking with Jesse Chen afterwards; he and I were both wishing that we'd had more time to grasp all the implications. Then met Rich Hickey in the elevator who suggested the article "On State and Identity" on the Clojure.org website:
ReplyDeletehttp://clojure.org/state