2 ms·

I studied at Oxford when Hoare was the lead of the Programming Research Group. We did a lot of CSP stuff and my entire DPhil is CSP and occam. I would recommend

I studied at Oxford when Hoare was the lead of the Programming Research Group. We did a lot of CSP stuff and my entire DPhil is CSP and occam. I would recommend reading the CSP book [1] if you really want to know about CSP. [1] http://www.usingcsp.com/cspbook.pdf http://www.usingcsp.com/cspbook.pdf

fidotron 3y ago
Hoare is so much more readable than Milner as well, which I think accounts for a large part of why the pi calculus gets ignored. I was at Loughborough and we had to do real time systems using occam . . . it was great! The problem with occam (and transputers generally) is they are a bit too static at build time, and so are very fault intolerant, which isn’t great in many real world applications. Consequently I tend to think CSP works in the small and the Actor pattern is better in the large.
JonChesterfield 3y ago
The differences between the original paper and the book are interesting too, I'm told that roughly reflects things he learned from the occam production effort. In particular I suspect there is a useful correlation between synchronous message passing and maintaining program invariants which is obfuscated if your primitive is asynchronous queues.
- jgrahamc 3y ago
  What would you highlight? The big thing from my perspective was that there are no channels in the original CSP. There's just synchronization on shared events. Asynchronous queues are a good way of delaying deadlocks!
  - JonChesterfield 3y ago
    The 1978 paper proposes a reasonable set of primitives and then walks through prose examples with them. The book proposes roughly the same primitives (channels are the big change, but stop is barely in the paper) and describes them in a formal notation for state machines. It's the difference between a sketch of a plausible idea and writing down the mathematics. Related though much later, ocaml https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents observed that the send/recv primitives make less sense than a swap primitive. Between occam and the current ocaml effort, concurrent ML is the same sort of model with the details really well thought through (e.g. a thread executing stop gets garbage collected).

fidotron 3y ago

Hoare is so much more readable than Milner as well, which I think accounts for a large part of why the pi calculus gets ignored. I was at Loughborough and we had to do real time systems using occam . . . it was great! The problem with occam (and transputers generally) is they are a bit too static at build time, and so are very fault intolerant, which isn’t great in many real world applications. Consequently I tend to think CSP works in the small and the Actor pattern is better in the large.

JonChesterfield 3y ago

The differences between the original paper and the book are interesting too, I'm told that roughly reflects things he learned from the occam production effort. In particular I suspect there is a useful correlation between synchronous message passing and maintaining program invariants which is obfuscated if your primitive is asynchronous queues.

jgrahamc 3y ago
What would you highlight? The big thing from my perspective was that there are no channels in the original CSP. There's just synchronization on shared events. Asynchronous queues are a good way of delaying deadlocks!
- JonChesterfield 3y ago
  The 1978 paper proposes a reasonable set of primitives and then walks through prose examples with them. The book proposes roughly the same primitives (channels are the big change, but stop is barely in the paper) and describes them in a formal notation for state machines. It's the difference between a sketch of a plausible idea and writing down the mathematics. Related though much later, ocaml https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents observed that the send/recv primitives make less sense than a swap primitive. Between occam and the current ocaml effort, concurrent ML is the same sort of model with the details really well thought through (e.g. a thread executing stop gets garbage collected).