Lambda the Ultimate

My recent approaches have involved E-vat like models together with pipeline parallelism, which enable me to reason compositionally about memory usage, resource management, and process control.

I'm not sure promises/futures truly enable compositional reasoning about memory usage or resource management. They have lazy default semantics, which is notoriously difficult to reason about in languages that aren't lazy everywhere (and often even there).

Futures and promises have a lot of problems, I agree. I don't use them. I've periodically contemplated promises, futures, and variations (such as rational types or Oz-like logic variables). But I repeatedly reach the same conclusion: these techniques hinder generic equational reasoning (since any function that potentially outputs a promise must be understood in its entire context) and it becomes difficult to reason compositionally about dataflow, divergence, and resource/memory use.

Pipeline parallelism doesn't depend on promises, and is really a separate concept from them. It does depend on having clear pipelines that can be computed in an earlier stage from the runtime data. But this can be achieved using a streaming data model, or arrows, or reactive dataflow signals.

The utility of 'vats' is having little islands that are internally consistent, and have simple snapshot-consistency relationships with other vats. A lot of malign data races can be avoided entirely, while allowing for open systems to have a little bit of temporary inconsistency.

I think replay is a good way forward. Rather than package a value up as a promise, have the computation return "not yet" and allow the task to continue executing with that value. When the computation has produced the value, re-execute the task with the right value. Of course to make this work, we must be able to undo and redo any stateful operations, but this is what I'm basing Glitch on anyways to support incremental computation as well as live programming. Of course, you are now executing your tasks multiple times, but I don't think task computation is really bottleneck for these applications.

Performance-oriented pipeline parallelism is a whole different barrel of fish where you want a statically known graph and highly encapsulated communication between vertices via graph edges only. Synchronous execution might even be a requirement for something really fast like CUDA.

As the paper makes clear, determinism and stable multithreading are not mutually exclusive. Indeed, they can be used together, i.e., SMT can be an addition to DMT.

It appears that Junfeng Yang came out of Dawson Engler's group at Stanford. And much like Dawson, seems to be approaching the problem from the "how can I find or fix problems in sloppy code?" direction rather than from the "how can I not write sloppy code in the first place?" direction. This, of course, has the pragmatic benefit that it lets developers keep doing the same things they've always done with the languages they're comfortable with.

Junfeng and Dawson are closer to systems people in that vain "how can I fix problems with current programming models" is more of the systems approach vs. the "how can I avoid problems with new programming models" of PL people. There is a lot of overlap of course, I work in a systems team where I face this divergence in thinking almost every day. I actually discussed these differences with Junfeng when he visited our group a few months ago; I think more bridging work in this area would be useful.

That's a good way to look at it.

How would you augment the Erlang/OTP approach?

Unfortunately, Erlang/OTP does not properly support the Actor Model. See Actor Model of Computation.

I am aware of your contributions, Dr. Hewitt. But that wasn't the question.

Is there anything practically wrong with the Erlang/OTP approach? To wit (pi), how many 9s has a 'correct' implementation of an Actor model achieved?

The Actor Model claims to embody current theory and practice for
(concurrent) computation.

Which of the principles of the Actor Model are satisfied by
Erlang/OTP? And which principles of the Actor Model are violated
by Erlang/OTP?

To what extent are the strengths of Erlang/OTP due to adherence to
principles of Actors. And to what extent are the limitations of
Erlang/OTP due to violating principles of Actors.

I would think you & possibly Dr. Armstrong have the authoritative answers to your questions.

Practically speaking, Erlang/OTP delivers the goods in fault tolerance, in the field. Per my understanding, this is due to OTP's primary principle of expecting and embracing component failures. Erlang's (however un-canonical) foundations in Actor model and process isolation allows for OTP supervisory components to achieve the design goals of OTP.

So the question remains as to (a) what is wrong with this practical approach ala Erlang/OTP? and (b) in what sense do implementations of the orthodox Actor model improve on the empirical results we have from Erlang/OTP approach?

And with all due respect, you seem to exhibit the same tin ear that Godel displayed in response to Wittgenstein's 'so what?' critique of possibility of paradox in self referential logic. Just as your "direct logic" is a practical approach -- my pet name for DL is 'blue collar logic' -- for getting things done and staying clear of the difficulties inherent in formalizing 'meta-physics' and 'intuition', a practical approach to concurrency ala Erlang/OTP has proven itself repeatedly in the field (where it counts for 'Engineers'), never mind its deviation from the Canon of Actor Model.

As an aside, this little interaction of ours has inspired what I call the "Hewitt Test" "contra" "Turing Test". The test setup is just like the Turing Test. There is a room with a teletype. A random person sits behind the teletype and poses a question. If the response to the query (regardless of content) is "The Actor Model", then we know Carl Hewitt is behind the curtain.

/All the best!

[edit 09-18-2015]:
Saw this post of mine a few days ago and find the personal matter entirely unacceptable. Dr. Hewitt, should you see this, please accept my apology.

But the actor model.

:)

I've never successfully engaged Hewitt in a meaningful discussion. It's as though he defines concurrency in terms of the actor model, so he can't even contemplate relative strengths and weaknesses of alternatives. If it isn't actor model, then it isn't true concurrency, nothing more to discuss.

How can (concurrent) computation be rigorously defined?

The first attempt was to define computation rigorously using the
lambda calculus. However, it became apparent that the lambda
calculus is inadequate and various alternatives were developed, e.g.,
Petri nets. In 1972, the Actor Model was invented and shown to
encompass the known computational methods, e.g. Petri nets, lambda
calculus, interrupt handlers, arbiters, semaphores, threads, locks,
monitors, etc. Also, using the Actor Model, it was proved that
nondeterministic Turing machines cannot implement concurrent
computation.

What is your proposal to rigorously define concurrent computation?

Informally, concurrent describes any phenomenon that coincides spatially and temporally. Concurrent computation can be formalized if you also formalize the spatial-temporal model. Actors model does achieve concurrency, of course. So do cellular automata, threads, CSP, event calculi, temporal logic, and a number of other models.

the Actor Model was invented and shown to encompass the known computational methods

Sure. But this is a statement of universality or generality, not concurrency.

using the Actor Model, it was proved that nondeterministic Turing machines cannot implement concurrent computation

Not at all. You have argued that actors model can express some behaviors that a nondeterministic Turing machines cannot express. (This 'proof' relies on a non-constructive assumption of 'fairness' in Actors model; intuitionists may be unwilling to accept this proof.) But this is, again, a claim of generality, that seems irrelevant to concurrency.

You should make an effort to distinguish concurrency from generality. They are different concepts, both informally and formally. If you are unable to comprehend and make clear distinctions between concurrency and other concepts, then there is no value in discussing concurrency with you.

See LtU post the following location:
Nondeterministic state machines cannot implement concurrency

Yes, that post is a nice point of evidence that Carl Hewitt conflates 'concurrency' with some form of 'generality' - an ability to express all computations. Which supports a conclusion that there is little value in discussing concurrency with him. Thanks. Bye.

Because of the efficiency of many-core computer architectures and
the fact that almost all computers are connected to the network,
computation these days means concurrent computation, i.e.,
in practice all computation is becoming concurrent computation.