With CPS it seems like you have to build and then instrument a lot of additional machinery (CPSMath.pow, seriously?) and occasionally turn your code inside out (the loop completion example) in order to rarely get a more convenient way to extend certain types of computations.
The author also seems to lay the fact that Javascript is often implemented in an odd way in browsers (the iframe complaint) to find fault with the entirety of the concept of Promises in general, which doesn't seem appropriate to the discussion here.
Finally.. he suggests that CPS shows it's power in a "probabilistic programming language" that executes blocks of code in a random order. Perhaps I shouldn't judge an author by their contents, but I think this author is so in love with the idea of CPS that he can't see how ugly and mostly mismatched it's implementations are.
Don't use CPSMath.pow. It's just in there to demonstrate that it's easy to turn direct style into CPS style. When a function doesn't need to be asyncronous, just use direct style.
Friendly recommendation: when writing examples it's much nicer to use a real use-case rather than abstract functions like `cps4()` or `CPSadditionalProcessing()`.
The author also seems to lay the fact that Javascript is often implemented in an odd way in browsers (the iframe complaint) to find fault with the entirety of the concept of Promises in general, which doesn't seem appropriate to the discussion here.
Finally.. he suggests that CPS shows it's power in a "probabilistic programming language" that executes blocks of code in a random order. Perhaps I shouldn't judge an author by their contents, but I think this author is so in love with the idea of CPS that he can't see how ugly and mostly mismatched it's implementations are.