6 ms·

Talk with Rich Hickey: Time is the New Memory

83 points by alrex021 17y ago

vdm 17y ago
I think the Date class is an unfortunate example to use, its too prone to being confused with the idea of a timeline of mutable state. Maybe a better example to use would be the concept of a document, and that parts of it don't change while you're reading it. On the other hand, his audience will always be familiar with the Date class... I've been following Rich's work for a while and I felt myself almost slip into confusion.
- thunk 17y ago
  I think he chose it specifically because of the pleasing self-similarity -- it's sort of a joke. After all, what kind of problem is a mutable date? A time problem, of course.
10ren 17y ago
I wonder if there is an entirely different way to reason about computation, other than mutable state, which coincides with our intuitions based on everyday experience of the physical world; and immutable state, which coincides with the powerful and abstract approach of our mathematics. Alas, mutable and immutable would appear to cover all the cases.
- lucifer 17y ago
  The issue isn't computation, it is modeling. The next order of evolution for computation is quantum computation. What R Hickey is addressing is modeling. I think the modeling problem could be alternatively addressed by unlearning the notion (conceit?) that every program is a representation/simulation (which is where (domain) state creeps in) and instead embrace a descriptive/measurement approach. Or more precisely, to accept that a program is always orthogonal to the domain model and give up chasing after the holy grail/folly of seeking a paradigm to express "reality" in computer instructions. One could argue that this is what FP is all about, but suggestion here is that the issue is fundamentally the conceptual view of the programmer and it can apply equally to OO or any other paradigm of programming. For example, the "Date" case he outlines conceptually works if one is to suspend disbelief and accept the notion that a "Date" type object is really a point in time. "How can September 22, 2009 change?" But at some level this is just semantics. Would calling the "Date" object "DateDatum" cause a similar conceptual problem? DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now();
  - richhickey 17y ago
    > DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now(); Yes, this highlights the crux of the argument: MutableDate lastUpdate = now(); doSomething(); lastUpdate.changeInPlace(); versus: ImmutableDate lastUpdate = now(); doSomething(); lastUpdate = changedVersionOf(lastUpdate); In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them. Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate: TransactionalRef<ImmutableDate> lastUpdate = now(); or AtomicRef<ImmutableDate> lastUpdate = now(); or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".
tybris 17y ago
I'm sure he's a really smart guy, but he sounds like a Computer Science freshman who is just beginning to grasp the problems of concurrency and consistency (could be his way of explaining). We already know these things are hard. No reason to give it a new, vague name like "Time management".
- deleted 17y ago
  [deleted]
- gizmo 17y ago
  A computer science freshman? I'd rather argue the opposite -- that he's one of the few guys in Computer Science who comes up with something original AND builds a language that supports his ideas to see if they work in practice. Even if you don't think Hickley is on the right track, how can you not like his combination of hands on implementation and search for theoretical soundness?
  - lucifer 17y ago
    You recognize, of course, that the ironic fact of Clojure's implementation on top of JVM (using JVM concurrency mechanisms) argues against the very thesis he is putting forward.
    - loup-vaillant 17y ago
      How so ? Do you say the manual implementation of automatic time management is contradictory ? Automating things requires manual work. Interpreters, compilers, garbage collectors, STM etc are the same in this respect.
      - lucifer 17y ago
        Sorry, replied to the wrong comment. (Was addressing the "concurrency is hard" bit.)
  - jrockway 17y ago
    that he's one of the few guys in Computer Science who comes up with something original AND builds a language that supports his ideas to see if they work in practice. Not to discount Rich's work, but all of the ideas in Clojure have been well-known forever, and Haskell and ML implemented these ideas many, many years ago. Clojure lets you use these ideas with some Java libraries; that's its innovation. Also, I don't really get the whole time analogy, but I can't help but think he wants Comonads, which Clojure does not have. (And due to its type system, will never be able to support well.)
radu_floricica 17y ago
I just started reading Norvig's PAIP, and one of the things that surprised me was seeing lisp code written in a non-functional manner. Of course the code in PAIP evolves and the early iterations are "bad" on purpose, but it's amazing how obviously wrong some early patterns seemed just because I was used to Clojure's more functional style.
- lispm 17y ago
  no, they are not 'bad on purpose'. Peter Norvig shows how to get from quick bottom up prototypes to optimized code. The purpose is to quickly and cleanly as possible get a first version going and then improve that. Common Lisp programs make heavy use of side effects from imperative code, over destructive operations to the CLOS object system.
  - radu_floricica 17y ago
    I haven't programmed at all in lisp and less then a year in Clojure so my opinion doesn't carry much weight, but I did notice that a) imperative code is harder to read and b) later versions look more functional. So for what's worth I'm happy Clojure considers functional style and immutable data as defaults.
reginaldo 17y ago
Funny that Rich used the number 42 as a recurring example in the interview. After all, 42 is "the answer to life, the universe and everything" (really, just search on google), which basically is what he is trying to find.
gruseom 17y ago
What does this add to the discourse about mutable state? Is there any genuine insight here, other "hey it's kind of like about time"? If so, it ought to give rise to some new construct or technique that helps solve the problem, or even just a simplification of some well-known example. I guess he's trying to popularize the first principle of functional programming, but he's doing it in a confusing way that will inevitably breed further confusion. Look at the absolute silliness of the title for evidence of that.
- crc 17y ago
  "Its kind of like about time". That is the point. This is just concurrency control, and looking at as time is just a different perspective. (Actually, it is more than concurrency control, since he also talks about aliasing, but anyway..)I find that perspective intriguing. I am not worried that it will confuse people. Ideas and perspectives that don't have merit will lose out to more powerful and clearer ideas over time. Also, I have always had more clarity only after passing through a state of confusion.
  - gruseom 17y ago
    Ideas and perspectives that don't have merit will lose out to more powerful and clearer ideas over time. If there's one statement that the history of programming languages (to date) contradicts... :) Actually, I think I'm reacting more to the slides of Hickey's recent talk about this, which he called "deconstruction" and kept comparing to Whitehead. I think Clojure deserves better than that. The signs of guru worship are already appearing. I would have said that's a bad thing. On the other hand, maybe it's the way to grow.
- fauigerzigerk 17y ago
  What's your issue with the title? We did manual memory management in the past and we do manual time management now. I agree with him completely that managing the timing of parallel processes is the most pressing complexity issue in computing today.
  - gruseom 17y ago

83 points by alrex021 17y ago

vdm 17y ago

I think the Date class is an unfortunate example to use, its too prone to being confused with the idea of a timeline of mutable state. Maybe a better example to use would be the concept of a document, and that parts of it don't change while you're reading it. On the other hand, his audience will always be familiar with the Date class... I've been following Rich's work for a while and I felt myself almost slip into confusion.

thunk 17y ago
I think he chose it specifically because of the pleasing self-similarity -- it's sort of a joke. After all, what kind of problem is a mutable date? A time problem, of course.

10ren 17y ago

I wonder if there is an entirely different way to reason about computation, other than mutable state, which coincides with our intuitions based on everyday experience of the physical world; and immutable state, which coincides with the powerful and abstract approach of our mathematics. Alas, mutable and immutable would appear to cover all the cases.

lucifer 17y ago
The issue isn't computation, it is modeling. The next order of evolution for computation is quantum computation. What R Hickey is addressing is modeling. I think the modeling problem could be alternatively addressed by unlearning the notion (conceit?) that every program is a representation/simulation (which is where (domain) state creeps in) and instead embrace a descriptive/measurement approach. Or more precisely, to accept that a program is always orthogonal to the domain model and give up chasing after the holy grail/folly of seeking a paradigm to express "reality" in computer instructions. One could argue that this is what FP is all about, but suggestion here is that the issue is fundamentally the conceptual view of the programmer and it can apply equally to OO or any other paradigm of programming. For example, the "Date" case he outlines conceptually works if one is to suspend disbelief and accept the notion that a "Date" type object is really a point in time. "How can September 22, 2009 change?" But at some level this is just semantics. Would calling the "Date" object "DateDatum" cause a similar conceptual problem? DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now();
- richhickey 17y ago
  > DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now(); Yes, this highlights the crux of the argument: MutableDate lastUpdate = now(); doSomething(); lastUpdate.changeInPlace(); versus: ImmutableDate lastUpdate = now(); doSomething(); lastUpdate = changedVersionOf(lastUpdate); In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them. Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate: TransactionalRef<ImmutableDate> lastUpdate = now(); or AtomicRef<ImmutableDate> lastUpdate = now(); or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".

tybris 17y ago

I'm sure he's a really smart guy, but he sounds like a Computer Science freshman who is just beginning to grasp the problems of concurrency and consistency (could be his way of explaining). We already know these things are hard. No reason to give it a new, vague name like "Time management".

deleted 17y ago
[deleted]
gizmo 17y ago
A computer science freshman? I'd rather argue the opposite -- that he's one of the few guys in Computer Science who comes up with something original AND builds a language that supports his ideas to see if they work in practice. Even if you don't think Hickley is on the right track, how can you not like his combination of hands on implementation and search for theoretical soundness?
- lucifer 17y ago
  You recognize, of course, that the ironic fact of Clojure's implementation on top of JVM (using JVM concurrency mechanisms) argues against the very thesis he is putting forward.
  - loup-vaillant 17y ago
    How so ? Do you say the manual implementation of automatic time management is contradictory ? Automating things requires manual work. Interpreters, compilers, garbage collectors, STM etc are the same in this respect.
    - lucifer 17y ago
      Sorry, replied to the wrong comment. (Was addressing the "concurrency is hard" bit.)
- jrockway 17y ago
  that he's one of the few guys in Computer Science who comes up with something original AND builds a language that supports his ideas to see if they work in practice. Not to discount Rich's work, but all of the ideas in Clojure have been well-known forever, and Haskell and ML implemented these ideas many, many years ago. Clojure lets you use these ideas with some Java libraries; that's its innovation. Also, I don't really get the whole time analogy, but I can't help but think he wants Comonads, which Clojure does not have. (And due to its type system, will never be able to support well.)

radu_floricica 17y ago

I just started reading Norvig's PAIP, and one of the things that surprised me was seeing lisp code written in a non-functional manner. Of course the code in PAIP evolves and the early iterations are "bad" on purpose, but it's amazing how obviously wrong some early patterns seemed just because I was used to Clojure's more functional style.

lispm 17y ago
no, they are not 'bad on purpose'. Peter Norvig shows how to get from quick bottom up prototypes to optimized code. The purpose is to quickly and cleanly as possible get a first version going and then improve that. Common Lisp programs make heavy use of side effects from imperative code, over destructive operations to the CLOS object system.
- radu_floricica 17y ago
  I haven't programmed at all in lisp and less then a year in Clojure so my opinion doesn't carry much weight, but I did notice that a) imperative code is harder to read and b) later versions look more functional. So for what's worth I'm happy Clojure considers functional style and immutable data as defaults.

reginaldo 17y ago

Funny that Rich used the number 42 as a recurring example in the interview. After all, 42 is "the answer to life, the universe and everything" (really, just search on google), which basically is what he is trying to find.

gruseom 17y ago

What does this add to the discourse about mutable state? Is there any genuine insight here, other "hey it's kind of like about time"? If so, it ought to give rise to some new construct or technique that helps solve the problem, or even just a simplification of some well-known example. I guess he's trying to popularize the first principle of functional programming, but he's doing it in a confusing way that will inevitably breed further confusion. Look at the absolute silliness of the title for evidence of that.

crc 17y ago
"Its kind of like about time". That is the point. This is just concurrency control, and looking at as time is just a different perspective. (Actually, it is more than concurrency control, since he also talks about aliasing, but anyway..)I find that perspective intriguing. I am not worried that it will confuse people. Ideas and perspectives that don't have merit will lose out to more powerful and clearer ideas over time. Also, I have always had more clarity only after passing through a state of confusion.
- gruseom 17y ago
  Ideas and perspectives that don't have merit will lose out to more powerful and clearer ideas over time. If there's one statement that the history of programming languages (to date) contradicts... :) Actually, I think I'm reacting more to the slides of Hickey's recent talk about this, which he called "deconstruction" and kept comparing to Whitehead. I think Clojure deserves better than that. The signs of guru worship are already appearing. I would have said that's a bad thing. On the other hand, maybe it's the way to grow.
fauigerzigerk 17y ago
What's your issue with the title? We did manual memory management in the past and we do manual time management now. I agree with him completely that managing the timing of parallel processes is the most pressing complexity issue in computing today.
- gruseom 17y ago