&gt; The one bone I have to pick is the juxtaposition of PFP and imperative as opposites.<p>Well, I most certainly didn&#x27;t say FP and imperative are opposites; quite the contrary: <i>most</i> FP languages are imperative. Part of the confusion is that there is no definition of FP. PFP, OTOH, <i>is</i> well defined: it is a style of programming where <i>all</i> functions are pure. If you <i>can</i> write impure functions, you&#x27;re not doing PFP, and if you&#x27;re doing PFP, you can&#x27;t write impure functions.<p>&gt; I&#x27;m not sure I buy the idea that scoped continuations should replace this monad usage.<p>I&#x27;m not entirely sure what you mean by &quot;this usage&quot; (lists?), but, like I say in the talk, I think monads are great for parallel streams, where you explicitly don&#x27;t care about the stack context.<p>&gt; I wonder how this jives with the actor model... When the author mentioned the thread being the atom of imperative programming, actors immediately came to mind.<p>Exactly. Threads (and by that I mean any thread implementation, not just kernel threads) are the best use of continuations, and blocking actors like Erlang&#x27;s (or our own Quasar) make great use of (lightweight) threads, as do Go&#x27;s goroutines (and Quasar fibers).<p>&gt; may come down to how easily it can be expressed and comprehended within real programming languages. I found the examples in the original talk and the blog post to both be rather difficult to follow.<p>My opinion is that it&#x27;s not important for scoped continuations to be directly exposed at all, and if they are, they should be rarely used directly. Using them to create lightweight threads solves almost all of the problems with the monadic style, and the code looks just like any plain-old thread-blocking code (we&#x27;ve had very good success with that in Quasar; Code stays the same, but instead of blocking a kernel thread, it blocks a fiber; the APIs don&#x27;t even need to change).<p>&gt; The former, probably because of the use of = to select the scope<p>I admit that when I gave the talk the precise details of the API and usage weren&#x27;t yet clear to me, which is why I wrote the post.<p>&gt; because of the verbosity of Java<p>Where does Java&#x27;s verbosity bother you here? (although I&#x27;m probably biased, as I like Java&#x27;s, or Go&#x27;s, intentional verbosity)