3 ms·
> Technically this breaks with the "no side-effects" rule, but I think it's an acceptable compromise since the effect would never have any chance of coming back
by rtfeldman 5y ago
> Technically this breaks with the "no side-effects" rule, but I think it's an acceptable compromise since the effect would never have any chance of coming back around and impacting your code's behavior later on. It's fully external.
Something to consider: if people come to rely on the logging in production (not just for debugging), and then you later do performance optimizations like memoization which skip calling a pure function because you know what answer it will give, then it'll break people's production code.
You can discourage it in the docs of course, but Hyrum's Law (plus my own experience with seeing how the equivalent Debug.log has been used in Elm) makes it safe to assume it'll happen!
- brundolf 5y agoI should look into Elm's approach; tbh I've been looking to Elm for battle-tested answers to lots of these questions, even though I'm also doing several things very differently from Elm With that said- I'm seeing this as purely a `console.log` feature, not a generic logging feature that could go to some arbitrary logging service. And become a part of a company's infrastructure. I guess in a server context even console logging could be abused that way... but at a certain point there's only so much you can do to protect the user from themselves :)