Fun fact: In contrast to process algebras like CSP, there is the Actor model. Instead of using an intermediary channel, the Actor model sends messages directly to a recipient process. These two message-based models of concurrency have influenced each other for decades.
I do miss PAR's synchronization semantics, which Go programmers know as the "sync.WaitGroup" idiom. Given the number of times I see Go developers asking about synchronizing goroutine termination perhaps having some form of concurrent control structure atop 'go' could help. Or maybe not - they'd just start asking about their inability to terminate :) At least PAR is easy enough to simulate (I wrote myself a little 'par' package to hide the WaitGroup manipulations with functions/closures as the [CSP] process bodies).
I was a teenager at that time and I remember that the Occam code made little Sense to me
In a world of docs on tap and Q&A forums aplenty, learning an esoteric branch of a small, ageing language provided a crash course in concurrent programming and a DIY mentality to problem solving that our Java assignments maybe didn't insist on.
It doesn't look like much has changed but it was nice to re-read all the same!
Great platform for embedded audio! www.xmos.com
He told me about the language over dinner and it seemed really interesting but I think he left me with the impression at the time that it was not for mainstream everyday programming.
Yet as others have pointed out, CSP has survived and is now embodied in ‘go’.
One of my classmates went off to Inmos - though unfortunately lost touch with him...
At least I couldn't find one. Anybody?
The language never got traction because it was non-portable, tied to a doomed hardware platform, and had extremely rudimentary support for data structures. One-trick languages don't usually attract much attention.