Michael Schoonmaker

@getify, Running simulations independent of framerate should be part of your strategy for adjusting the play experience to lower-powered devices. If the simulations run twice as slow on a 30...

@mikebryant Is this desirable? I was just considering adding the same behaviour, but I'd like a quick 👍 before I write the code for it. If so, I'm happy to...

I can't say I agree. Basing the sync/async behaviour on the presence of a callback argument seems like it would surprise a lot of developers. A similarly surprising example I...

It changes the mechanics considerably. Take, for example: ``` // Sync version writeSomeFile(1, 2) // Because this is sync, I can make guarantees around the file's state. // Async version...

I don't know what value this provides over our other messages (like the new "report" that tells you of missed stubbings). Do you run into this case often?

What's the timing of these messages now? On `reset`? Never?

Is this something we _can_ do during `reset`? Otherwise, I fear `whatWentWrong` would just become a part of some `afterEach` boilerplate.

That, or even an option: `reset({ printReport: true })` I think `reset` could be a good place to put these kinds of features in the future. It has little effect...

Probably. The only issue I can think of would be with unix pipes, but I think that was resolved. (It used to be that `node script-with-console-log.js | whatever` would blow...

Thinking through the cases you brought up, I think the existing behaviour might be the _least_ surprising overall. If we _do_ anything, maybe we can add a more visible warning...