Occam may not have become mainstream, but it showed Hoare's CSP channels in a programming language. Now days we see channels in Go, whose "select" is similar to Occam's "ALT".
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 really wish Go's select had guard clauses. The need to nil channels feels like a hack. However I haven't actually had much need for them but haven't written many things that would need them.
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 remember reading about Occam around 1987-89 in an Atari ST World magazine. Atari hade just announced the Transputer and the article introduced Occam as a way to program its parallel processor. https://en.m.wikipedia.org/wiki/Atari_Transputer_Workstation
I was a teenager at that time and I remember that the Occam code made little Sense to me
Anyone else here use ST's video decoding hardware with a Transputer as the controller in the mid 90's?
All the coding I did for this device used C, but ST's supplied development tools included an Occam compiler and occasionally the C reference docs would allude to an Occam construct.
Our course was still using the occam-π revision, listed in the article, to teach concurrent programming ~10 years ago.
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!
I did a lot of occam in the 1980s working with transputer-based machines (I wrote a sort of OS for the system our company was building to target TV/film animation). At the time Inmos marketing came up with the line "We want to make occam the FORTRAN of parallel processing." My response, referring to occam's lack of data structuring, was, "You have."
Any other XMOS developers here? I first encountered elements of Occam when using XMOS, David May’s successor to Inmos. Was surprised later to see that Go had inherited various features too.
Long ago I spent a week at a compiler workshop (on what was then the relatively new SSA form) and one of the other attendees worked on the occam compiler.
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’.
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.
I'm not sure I follow. If a topic is interesting, it's fine to post it here, even as a Wikipedia article, though of course more specialized sources are often more interesting.
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.