6 ms·

The transputer tech is a rich trove of forgotten ideas. Occam and Hoare's CSP book are especially interesting. Highly recommended. As in read the primary source

The transputer tech is a rich trove of forgotten ideas. Occam and Hoare's CSP book are especially interesting. Highly recommended. As in read the primary sources, not blog posts about what people think CSP is.

jgrahamc 3y ago
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).
karmakaze 3y ago
I wasn't aware that there was widespread misunderstanding about what CSP is. Mind listing a common misconception, so I can tell I'm among the misinformed. I haven't read up on it specifically so the links in these threads are now on my radar. As much as I know is through running into the ideas from Erlang/Elixir and Pony. The only other thing I recall reading is as soon as there's a buffer, CSP breaks down losing determinism or some-such. I also ran into the Inmos Transputer while I was at UWaterloo but didn't get a chance to use it myself, due to limited availability at the time.
- JonChesterfield 3y ago
  Lots of people have the idea that message passing is good. Maybe slow, but easier than directly hammering on shared memory. Synchronous message passing, as in wait for the other guy then swap, is a different thing to pushing work into a queue to be dealt with later. Not just a buffer of size one; the current thread actually blocks until the exchange occurs. It's another step in the direction of decreased throughput for decreased entropy and I think it's an important one. I personally missed the distinction for a good decade or so, seems plausible others have likewise missed it.
  - BoiledCabbage 3y ago
    And between CSP and elixir, which promotes synchronous message passing and which promotes the asynchronous/queue approach?
    - Jtsummers 3y ago
      CSP communication blocks until both sides are ready for the communication. You can create a process which acts as a buffer so that an outputting process is able to communicate so long as the buffer has capacity (and if the buffer size is unbounded then it will never be blocked, at least as long as there is sufficient memory).
dboreham 3y ago
Not exactly forgotten if you use golang.

jgrahamc 3y ago

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

karmakaze 3y ago

I wasn't aware that there was widespread misunderstanding about what CSP is. Mind listing a common misconception, so I can tell I'm among the misinformed. I haven't read up on it specifically so the links in these threads are now on my radar. As much as I know is through running into the ideas from Erlang/Elixir and Pony. The only other thing I recall reading is as soon as there's a buffer, CSP breaks down losing determinism or some-such. I also ran into the Inmos Transputer while I was at UWaterloo but didn't get a chance to use it myself, due to limited availability at the time.

JonChesterfield 3y ago
Lots of people have the idea that message passing is good. Maybe slow, but easier than directly hammering on shared memory. Synchronous message passing, as in wait for the other guy then swap, is a different thing to pushing work into a queue to be dealt with later. Not just a buffer of size one; the current thread actually blocks until the exchange occurs. It's another step in the direction of decreased throughput for decreased entropy and I think it's an important one. I personally missed the distinction for a good decade or so, seems plausible others have likewise missed it.
- BoiledCabbage 3y ago
  And between CSP and elixir, which promotes synchronous message passing and which promotes the asynchronous/queue approach?
  - Jtsummers 3y ago
    CSP communication blocks until both sides are ready for the communication. You can create a process which acts as a buffer so that an outputting process is able to communicate so long as the buffer has capacity (and if the buffer size is unbounded then it will never be blocked, at least as long as there is sufficient memory).

dboreham 3y ago

Not exactly forgotten if you use golang.