I understand why some people want sequential semantics in parallel programs: it's very easy to reason about, especially for those who are used to sequential rea

I understand why some people want sequential semantics in parallel programs: it's very easy to reason about, especially for those who are used to sequential reasoning (like most imperative programmers). Certainly, if your goal is to use parallelism to speed up your existing software (and this is, indeed, Cilk's goal) then it makes lots of sense. But most software programs can accept a little nondeterminism. Object-oriented design (at least, GOOD design) is built around the fact that your object's methods might be called at any time; you're just providing an interface. So (this was a programming language idea I was working on for a while) why don't we make it work that way? Make all method calls asynchronous, make methods transactions upon objects, and just schedule as many method calls in parallel as you can get your hands on. Good for server design, potentially good for parallelizing existing code (you'd still have to go through it and make sure it made sense -- no reaching into other people's objects and tweaking their internal state, etc.) I guess my point is that while serial equivalence is a strong property, it's not necessary for many programs, and it completely prevents the existence of some, especially server-type programs.