4 ms·

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 (cou

by 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.)
  - richhickey 17y ago
    Yes, Clojure is full of old ideas. I've never claimed otherwise. Unfortunately, they have yet to gain significant traction as currently embodied. Clojure is just an attempt to make them palatable and practical (and fun). I would never argue against someone who preferred Haskell. As far as comonads, no - monads and comonads are essentially threaded through a single computation. The reference types I'm talking about are like, and for similar situations as, Haskell's MVars and STM TVars, which wouldn't exist if, e.g., state monads were sufficient.
    - jrockway 17y ago
      OK, now that you mention MVar/TVar, I think I understand I understand your argument better. I think MVars and TVars are mostly a performance hack (like most other uses of state in general and ST or IO in Haskell specifically). Theoretically, many programs written in terms of MVars could be written in terms of spawning a new thread for each read/write pair. This would be easier to reason about, but probably slower. A common use of MVars: f x = pure computation g h m = forever $ hGetChar h >>= putMvar m do mvar <- newEmptyMVar forkIO $ liftM f (takeMVar m) forkIO $ g a mvar forkIO $ g b mvar <wait for exit condition> All we do is read from two handles, concurrently, and eval f for every byte on either handle. The MVar is a natural way of expressing this, but it does lead to potentially undesirable side effects. Writing it in a functional way would probably be better: f x = pure computation g h f = forever $ liftM f (hGetChar h) do forkIO $ g a f forkIO $ g b f ... There is now no shared state, since the problem doesn't actually require any. (We could use continuation passing style if we needed to keep state.) Anyway, I am still not sure how Clojure encourages the reference-less style.
lucifer 17y ago
http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...
jimbokun 17y ago
If "we" already know these things are hard, why are "we" all programming in languages with mutable state? That seems to indicate that "we" are all idiots, or masochists. I found the analogy to garbage collection just right. It's obvious now that for large parts of the problem space of writing computer programs, having garbage collection built into the language makes programs significantly easier to write and understand. Joel Spolsky made the argument that object oriented programming didn't do nearly as much to make programming more productive as automated memory management did, and I agree. So why not take this other problem that is very hard to reason about, and build constructs into the language that take care of it for you automatically? I think the fact this seems so obvious to you that it's hardly worth saying points to how powerful the argument is. If it's so obvious, why is almost everyone still programming with mutable state and with so little support for "time management" constructs? Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine?
- tybris 17y ago
  > why are "we" all programming in languages with mutable state? My argument is not against closure or using immutable objects. My argument is against trying to rebrand a problem that has been well-known and well-studied for over 40 years. Clojure does a bit of copying (memory management, not "time management") to force you to avoid concurrency problems that arise in some scenarios. Arguably that is a good thing, because people tend to think of concurrency when it's too late. However, it too ultimately has a mutable authoritative source where the same issues arise. Moreover, the hardest concurrency and consistency problems arise in distributed systems. Using Clojure certainly isn't the answer to that. > Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine? People "stubbornly clinge" to programming with free and malloc (in C), because it allows them to have very specific control over how their program will behave. This allows you to perform very effective optimizations. Moreover, because it is cumbersome, C programmers will avoid dynamic memory, which will again make your program faster and more durable. The same thing will apply to mutable objects. Clojure simply restricts you to a certain model, which is not necessarily most efficient. Does that mean Clojure is bad? No it means it's not the right tool for every job.
loup-vaillant 17y ago
Basically, the guy is saying that pervasive mutation hurts. If it takes buzzwords like "management" to make programmers understand that, I'm glad he uses them. We may already know concurrency and consistency are hard, but we do little to identify and eliminate the root causes. Those who do can show the bright side, like Rich Hickey does, or they can finger-point the dark side, like I do: http://theroleplayingprogrammer.blogspot.com/2009/06/assignment-considered-harmfull.html http://theroleplayingprogrammer.blogspot.com/2009/06/assignm...
mbrubeck 17y ago
Maybe part of your problem is that his explanation in this particular interview is on a very basic level, using concepts that any freshman can understand. For a deeper version of Hickey's ideas, see his talk from the JVM language summit, or some of the docs on clojure.org. (Or better yet, read the Clojure source code...) http://news.ycombinator.com/item?id=829268 http://news.ycombinator.com/item?id=829268 http://clojure.org/state http://clojure.org/state

by tybris 17y ago

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.)
- richhickey 17y ago
  Yes, Clojure is full of old ideas. I've never claimed otherwise. Unfortunately, they have yet to gain significant traction as currently embodied. Clojure is just an attempt to make them palatable and practical (and fun). I would never argue against someone who preferred Haskell. As far as comonads, no - monads and comonads are essentially threaded through a single computation. The reference types I'm talking about are like, and for similar situations as, Haskell's MVars and STM TVars, which wouldn't exist if, e.g., state monads were sufficient.
  - jrockway 17y ago
    OK, now that you mention MVar/TVar, I think I understand I understand your argument better. I think MVars and TVars are mostly a performance hack (like most other uses of state in general and ST or IO in Haskell specifically). Theoretically, many programs written in terms of MVars could be written in terms of spawning a new thread for each read/write pair. This would be easier to reason about, but probably slower. A common use of MVars: f x = pure computation g h m = forever $ hGetChar h >>= putMvar m do mvar <- newEmptyMVar forkIO $ liftM f (takeMVar m) forkIO $ g a mvar forkIO $ g b mvar <wait for exit condition> All we do is read from two handles, concurrently, and eval f for every byte on either handle. The MVar is a natural way of expressing this, but it does lead to potentially undesirable side effects. Writing it in a functional way would probably be better: f x = pure computation g h f = forever $ liftM f (hGetChar h) do forkIO $ g a f forkIO $ g b f ... There is now no shared state, since the problem doesn't actually require any. (We could use continuation passing style if we needed to keep state.) Anyway, I am still not sure how Clojure encourages the reference-less style.

lucifer 17y ago

http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

jimbokun 17y ago

If "we" already know these things are hard, why are "we" all programming in languages with mutable state? That seems to indicate that "we" are all idiots, or masochists. I found the analogy to garbage collection just right. It's obvious now that for large parts of the problem space of writing computer programs, having garbage collection built into the language makes programs significantly easier to write and understand. Joel Spolsky made the argument that object oriented programming didn't do nearly as much to make programming more productive as automated memory management did, and I agree. So why not take this other problem that is very hard to reason about, and build constructs into the language that take care of it for you automatically? I think the fact this seems so obvious to you that it's hardly worth saying points to how powerful the argument is. If it's so obvious, why is almost everyone still programming with mutable state and with so little support for "time management" constructs? Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine?

tybris 17y ago
> why are "we" all programming in languages with mutable state? My argument is not against closure or using immutable objects. My argument is against trying to rebrand a problem that has been well-known and well-studied for over 40 years. Clojure does a bit of copying (memory management, not "time management") to force you to avoid concurrency problems that arise in some scenarios. Arguably that is a good thing, because people tend to think of concurrency when it's too late. However, it too ultimately has a mutable authoritative source where the same issues arise. Moreover, the hardest concurrency and consistency problems arise in distributed systems. Using Clojure certainly isn't the answer to that. > Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine? People "stubbornly clinge" to programming with free and malloc (in C), because it allows them to have very specific control over how their program will behave. This allows you to perform very effective optimizations. Moreover, because it is cumbersome, C programmers will avoid dynamic memory, which will again make your program faster and more durable. The same thing will apply to mutable objects. Clojure simply restricts you to a certain model, which is not necessarily most efficient. Does that mean Clojure is bad? No it means it's not the right tool for every job.

loup-vaillant 17y ago

Basically, the guy is saying that pervasive mutation hurts. If it takes buzzwords like "management" to make programmers understand that, I'm glad he uses them. We may already know concurrency and consistency are hard, but we do little to identify and eliminate the root causes. Those who do can show the bright side, like Rich Hickey does, or they can finger-point the dark side, like I do: http://theroleplayingprogrammer.blogspot.com/2009/06/assignment-considered-harmfull.html http://theroleplayingprogrammer.blogspot.com/2009/06/assignm...

mbrubeck 17y ago

Maybe part of your problem is that his explanation in this particular interview is on a very basic level, using concepts that any freshman can understand. For a deeper version of Hickey's ideas, see his talk from the JVM language summit, or some of the docs on clojure.org. (Or better yet, read the Clojure source code...) http://news.ycombinator.com/item?id=829268 http://news.ycombinator.com/item?id=829268 http://clojure.org/state http://clojure.org/state