Is concurrency hard?
Richard A. O'Keefe
Mon Nov 7 02:49:23 CET 2005
1) SQL: To harness the power of the relational database, we needed to think
in terms of sets and set theory.
Which the SQL designers didn't "get". (Amongst other things, SQL "relations"
are not sets.)
2) Event driven programming was another such technique that tripped up
countless very experienced programmers (and made life quite difficult for
the Windows and X11 worlds). But many did get it relatively quickly, in
particular the young and open-minded folk that Microsoft targeted at the
Microsoft? Event-driven programming came from Apple who got it from Xerox
who got it from real-time programmers.
Maybe CSP's silent disfavour has something to do with what became of its
author - according to the usingCSP website, he's at Microsoft Research.
What silent disfavour? Occam was based on it, and there was quite an
enthusiastic Occam/Transputer community for a while. The real problem
with CSP was that people drifted off into the development of rival
systems (CCS, mu-calculus, &c) and doing ever more intricate mathematics
about it. I had a student once at RMIT who did his thesis on designing
a concurrent object-oriented programming language and producing an
executable specification of it (using a CSP-ish extension of Standard ML).
He then tried to prove something or other about this specification correct
using bisimulation, and it was brutally hard. (If he had had the benefit
of advice from someone who had done it a few times before, it might not have
been. As it was, I found it as brutally hard as he did.)
Several specification languages have picked up CSP ideas.
More information about the erlang-questions