Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Communicating Sequential Processes (Hoare/Davies 2004)

usingcsp.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#11

Post by tel »

lostcolony wrote: post #6
tel wrote: post #4

Earlier quoted context omitted.

Distributed systems are really hard. This line has been endlessly parroted and, also, endlessly reproven. They are really hard. The major reason why they're hard is that your standard reasoning toolbox is insufficient. Understanding distributed systems means being aware of a much larger state space and how things like special relativity impact it (I'm being a bit flippant, but not actually inaccurate—message latency…

You reminded me of this - http://www.informit.com/articles/article.aspx?p=1768317 There are some interesting differences between CSP and Erlang (and Go, which arguably implements CSP a bit more closely than Erlang).

Yeah, to be clear: pure implementations of CSP are probably useless but "near" implementations are abound. I don't know Go, so Erlang came to mind... But it's definitely a little way from pure CSP.

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#12

Post by Jtsummers »

tel wrote: post #11
lostcolony wrote: post #6

Earlier quoted context omitted.

You reminded me of this - http://www.informit.com/articles/article.aspx?p=1768317 There are some interesting differences between CSP and Erlang (and Go, which arguably implements CSP a bit more closely than Erlang).

Yeah, to be clear: pure implementations of CSP are probably useless but "near" implementations are abound. I don't know Go, so Erlang came to mind... But it's definitely a little way from pure CSP.

I suspect most "pure" models are nigh useless on their own. They all require a bit of compromise to interact with the world, or exist as a subset of some other language/tool. However, they can be awesome for describing in specifications or analyses of systems. And when languages support them in some fashion (even if impure) it allows us to reduce the semantic distance between specification/requiremnets and implementation to a point where we can be confident that we've done things correctly.

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#14

Post by nova »

tel wrote: post #4
rtfm666 wrote: post #2

ok, I read the preface and while I was blasted out by the pretentiousness of the final line, I am interested about the content. However, I can't seem to get an overall 'what the hell is this useful for?' summary. The first part of the preface is all just abstract 'you will become better'. Can someone please enlighten me? I think Hoare is great and would like to know if this stuff would benefit me as a programmer.

Distributed systems are really hard. This line has been endlessly parroted and, also, endlessly reproven. They are really hard. The major reason why they're hard is that your standard reasoning toolbox is insufficient. Understanding distributed systems means being aware of a much larger state space and how things like special relativity impact it (I'm being a bit flippant, but not actually inaccurate—message latency…

> Understanding distributed systems means being aware of a much larger state space and how things like special relativity impact it (I'm being a bit flippant, but not actually inaccurate—message latency is not poorly modeled by special relativity).

This sound really interesting. Any recommendations to learn more about it?

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#15

Post by undershirt »

akilism wrote: post #7

CSPs are also implemented in Clojure's core.async This blog post helped me understand some use cases for CSP http://swannodette.github.io/2013/07/12/communicating-sequen...

Any game developers who use Co-Routines in Unity should know feel at home when making games for ClojureScript. Go-blocks give you the same power for animations and other timed scripts.

Here's a sample tetris row collapse animation using a go-block: https://github.com/imalooney/t3tr0s/blob/master/src/client/c...

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#16

Post by tel »

nova wrote: post #14
tel wrote: post #4

Earlier quoted context omitted.

Distributed systems are really hard. This line has been endlessly parroted and, also, endlessly reproven. They are really hard. The major reason why they're hard is that your standard reasoning toolbox is insufficient. Understanding distributed systems means being aware of a much larger state space and how things like special relativity impact it (I'm being a bit flippant, but not actually inaccurate—message latency…

> Understanding distributed systems means being aware of a much larger state space and how things like special relativity impact it (I'm being a bit flippant, but not actually inaccurate—message latency is not poorly modeled by special relativity). This sound really interesting. Any recommendations to learn more about it?

The classic paper on distributed clocks mentions it, Lamport's "Time, Clocks, and the Ordering of Events in a Distributed System" (http://research.microsoft.com/en-us/um/people/lamport/pubs/t...)

Re: Communicating Sequential Processes (Hoare/Davies 2004)

#17

Post by tel »

Jtsummers wrote: post #12
tel wrote: post #11

Earlier quoted context omitted.

Yeah, to be clear: pure implementations of CSP are probably useless but "near" implementations are abound. I don't know Go, so Erlang came to mind... But it's definitely a little way from pure CSP.

I suspect most "pure" models are nigh useless on their own. They all require a bit of compromise to interact with the world, or exist as a subset of some other language/tool. However, they can be awesome for describing in specifications or analyses of systems. And when languages support them in some fashion (even if impure) it allows us to reduce the semantic distance between specification/requiremnets and implementa…

Haskell is an interesting playground for this since it tries so hard to make "pure" practical. Interestingly, they achieve this to a large degree using monads. I think that idea is fairly generalizable, though, that pure formalisms can embed impure ones as models and then have those be executed by an RTS.
Post reply on HN