3 ms·
Aside: It's kind of amusing that "side effects" seems to have become a synonym for "effects". Usually "effects" are things you want to happen, whereas "side ef
by lomnakkus 8y ago
Aside:
It's kind of amusing that "side effects" seems to have become a synonym for "effects". Usually "effects" are things you want to happen, whereas "side effects" are things you don't necessarily want to happen (although they may ultimately prove beneficial.)
If one's type system actually models "effects" as first-class entites -- e.g via monads or capabilities -- then suddenly the distinction becomes much clearer. In typical imperative languages like JS, C or C++ it's clear as mud.
Of course, given that the browser'js JS engine is a VM unto itself it can just speculatively run everything until there's an "effect" and then 'roll back' (or remove the CoW data that was produced) so as to make it unobservable.
This is ingenious practical engineering.