4 ms·

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 ri

by 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
  Absolutely no one uses the phrase "time management" in this way. "I found a bug in my time management." <- Huh? That mutable state has something to do with time is a tautology. Nothing in the recent discussion shows it to add anything significant to what we do or think about the problem. The interview title takes this doodling and amplifies it into some sort of grand theory. I'd be embarrassed. I'm not criticizing Clojure at all, I'm criticizing this way of drawing attention to it (if that's what it is).
  - richhickey 17y ago
    Yes, there is a tautology, and I'm glad you understand it, but such understanding is not widespread I assure you. You are right, no one says "time management". I don't think they said "memory management" as often either, until there was automatic memory management (GC). But one thing is certain, most OO languages don't yet offer automatic _____ management, whatever it is to be called. People do say they have a "race condition" or a "deadlock", or simply "data corruption" often without connecting it at all to the unmanaged mutation of their objects. And before there was GC there was just "heap corruption", "double deletes" and "memory leaks". Management implies a manager, and there isn't one yet, so why would anyone say it? What I am advocating is that languages provide automatic management of "time". It's not a novel idea, yet it is still missing, and I think it is missing because there is no place to put it in OO strategies which conflate identity with state, with weak or missing notions of object values. But the phrase "mutable state" is broken, in a way that keeps people from understanding the problem and especially the potential solution. As soon as you consider state the value of something at a point in time, then mutation isn't the correct term, succession is, and the connection to time becomes clearer. FYI, I neither wrote nor uttered the title. The interview was a recording of a casual, no prep conversation following my keynote. It was not meant to be profound, nor an advertisement.
    - gruseom 17y ago
      I agree with much of this, but "time management" still seems like a half-baked metaphor for FP immutability and not a clarifying model, at least not yet. It's easy to explain the X to which "memory management" refers: allocating and freeing memory. Surely that was easy to understand even before the advent of GC. It's also easy to explain what memory is and point to where and how it is manipulated in code. I don't see how time is a programming construct in the way that memory or state is.

by gruseom 17y ago

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
Absolutely no one uses the phrase "time management" in this way. "I found a bug in my time management." <- Huh? That mutable state has something to do with time is a tautology. Nothing in the recent discussion shows it to add anything significant to what we do or think about the problem. The interview title takes this doodling and amplifies it into some sort of grand theory. I'd be embarrassed. I'm not criticizing Clojure at all, I'm criticizing this way of drawing attention to it (if that's what it is).
- richhickey 17y ago
  Yes, there is a tautology, and I'm glad you understand it, but such understanding is not widespread I assure you. You are right, no one says "time management". I don't think they said "memory management" as often either, until there was automatic memory management (GC). But one thing is certain, most OO languages don't yet offer automatic _____ management, whatever it is to be called. People do say they have a "race condition" or a "deadlock", or simply "data corruption" often without connecting it at all to the unmanaged mutation of their objects. And before there was GC there was just "heap corruption", "double deletes" and "memory leaks". Management implies a manager, and there isn't one yet, so why would anyone say it? What I am advocating is that languages provide automatic management of "time". It's not a novel idea, yet it is still missing, and I think it is missing because there is no place to put it in OO strategies which conflate identity with state, with weak or missing notions of object values. But the phrase "mutable state" is broken, in a way that keeps people from understanding the problem and especially the potential solution. As soon as you consider state the value of something at a point in time, then mutation isn't the correct term, succession is, and the connection to time becomes clearer. FYI, I neither wrote nor uttered the title. The interview was a recording of a casual, no prep conversation following my keynote. It was not meant to be profound, nor an advertisement.
  - gruseom 17y ago
    I agree with much of this, but "time management" still seems like a half-baked metaphor for FP immutability and not a clarifying model, at least not yet. It's easy to explain the X to which "memory management" refers: allocating and freeing memory. Surely that was easy to understand even before the advent of GC. It's also easy to explain what memory is and point to where and how it is manipulated in code. I don't see how time is a programming construct in the way that memory or state is.