Very interesting piece. It sounds a lot like how exceptions be used to implement non-error control flow [1]. The one bone I have to pick is the juxtaposition of PFP and imperative as opposites. Certainly it&#x27;s the case that PFPers can and do implement imperative logic monadically, but it&#x27;s also the case that imperative programmers often use frameworks that largely treat the business logic, where most of the programming is actually done, as more or less pure functions. Moreover, explicitly hybrid languages like JavaScript, Scala, Rust, Swift, etc. seem to be where a lot of the practical PL excitement is these days. I think the real debate is in the best patterns to use for particular generic problems. That&#x27;s the core of the blog post of course, I&#x27;m just disagreeing with some of the rhetorical framing.<p>Anyhow, the premise reminds me a lot of <i>What Color Is Your Function</i> [2] and its critique of async programming. I think monads are super useful and intuitive when representing data. Promises&#x2F;futures blew my mind, once I finally understood them, but I think there are important points about how they can become extremely cumbersome within a large architecture. I have to admit that I&#x27;m starting to agree that they may be a dead end, no matter how much syntactic sugar you sprinkle on it.<p>I think the big issue is that if you can&#x27;t pull data out of a monad, you can&#x27;t really encapsulate its logic. For containers, this isn&#x27;t much of a problem, because the monadic data structure is either inherent to the data itself or you can fold your way down to something more primitive. In those cases, the monadic model seems completely reasonable and very nicely encapsulated to me. I&#x27;m not sure I buy the idea that scoped continuations should replace this monad usage.<p>Connecting back with async programming, I wonder how this jives with the actor model, which has been so widely praised as a model of concurrency that is conceptually simple, easy to reason about, fault tolerant, and imperative. When the author mentioned the thread being the atom of imperative programming, actors immediately came to mind.<p>Lastly, much like monads, futures and every other abstraction out there, the usefulness of scoped continuations 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. The former, probably because of the use of = to select the scope and the latter because of the verbosity of Java. It would be interesting to see if there&#x27;s a syntax that really captures the operation in an intuitive way.<p>[1] <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;2742719&#x2F;how-do-i-break-out-of-a-loop-in-scala" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;2742719&#x2F;how-do-i-break-ou...</a><p>[2] <a href="http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-y...</a>