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.
I was curious how they implemented the side-effect checking, so I dug my way from the dev tools frontend eventually into v8, where it turns out to basically be a bunch of whitelist checks over bytecode and builtin javascript methods https://github.com/v8/v8/blob/e48d9788a4ef21d3bfffbc691bb02c...
I think Chrome really got traction over FF because of these dev tools.
I used to think "Firebug" was the greatest thing since slice bread when along came Chrome with its dev tools and soon every web developer started switching to Chrome because making sites with it is just too easy. When it comes to the internet I've often seen that targeting the technical users can pay back in many folds.
1) what happens when evaluating is going to take a lot longer that usual?
2) why the arguments list hint is using Flow syntax for optional (question mark before argument name)?
reply