

Communicating Sequential Processes (Hoare/Davies 2004) - jacquesm
http://www.usingcsp.com/

======
akilism
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...](http://swannodette.github.io/2013/07/12/communicating-sequential-
processes/)

~~~
undershirt
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...](https://github.com/imalooney/t3tr0s/blob/master/src/client/core.cljs#L188-L201)

------
chubot
I remember as a student that I was comfortable just looking at notation and
reasoning about things. CSP has a very simple notation.

But after a decade as a professional programmer, I somehow lost patience for
things that can't be run. Either experience taught me not to trust things that
don't run, or ideas are not fun unless you can poke at them, or my mind got
lazy. I just want to run things and see what happens.

I like the CSP model, but since nothing can be run in this book, unfortunately
I would look elsewhere to study it.

I've been playing with Standard ML and it seems like a nice way to
mathematically specify algorithms, but which can still also be run.

Also, Leslie Lamport's style of doing mathematics with runnable proofs seems
very interesting:
[http://scholar.google.com/scholar?cluster=145533208090118123...](http://scholar.google.com/scholar?cluster=14553320809011812377&hl=en&as_sdt=0,5&sciodt=0,5)

~~~
tel
I think they're two different UXen on two different reasoning methodologies:
equational versus interactive. Time spent in Haskell where both are
predominant has taught me that when used in synchrony they both have their
place, but I agree there's a weakness in using equational alone: it creates
great concepts but they are so substantially weakened by "operationalization"
that there's still a huge risk.

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

~~~
tel
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 is not poorly
modeled by special relativity). Most programmers use reasoning methods like
operational modeling (single threaded), guess-and-check, and unit testing.
These are simply completely insufficient.

If you want to model full distributed systems you might want to use something
like algebraic topology. It's a useful tool for understanding the entire state
space of a system and its valid transitions. It can be used to prove Paxos or
Raft are correct.
[https://www.ideals.illinois.edu/bitstream/handle/2142/33762/...](https://www.ideals.illinois.edu/bitstream/handle/2142/33762/top_dc.pdf?sequence=2)

Another method is to simplify a whole lot what a "distributed system" is and
hope to find a more analyzable model where more standard reasoning tools work.
CSP is one of these. It's a simpler model where some of the reasoning tools of
regular formal languages can be used to understand its operation.

The upshot is that CSP won't be as powerful as you could imagine possible when
building a distributed system, but it'll be massively more manageable so long
as its sufficient for your goals. It's, as such, formed the basis for some
popular distributed tools like Erlang.

~~~
nova
> 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?

~~~
tel
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...](http://research.microsoft.com/en-
us/um/people/lamport/pubs/time-clocks.pdf))

------
raphinou
I would have loved an epub version. Pdf on ebooks is suboptimal (i tried this
one)

