3 ms·

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

by 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.

by gizmo 17y ago

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.