I think the mindset of "functional is better than imperative" has led to great confusion. If you are approaching this from the point of view of mathematical tractability (which I agree with) then they are simply different mathematical structures. It's like saying "rings are better than groups". There are areas where the sequential, mutational aspects of imperative code are inessential, and using imperative code is inelegant there ... like using too rich a mathematical structure for a proof, rationals where you just need any monoid. The best place for functional code is "pure computation" without "side effects" like concurrency, I/O etc. But even this terminology gives a weird value judgment, "pure" vs "impure". And then you have this quest to "purify" the impure by simulating I/O with monads - this doesn't simplify the proofs at all, the putative goal of the exercise. Conal Elliott did a great job parodying this mindset with "The C language is purely functional".

Haskell will save us! We must purify the heretics! I never noticed this tone before. A Haskell programmer is walking down the street and steps in gum. He looks down and mutters under his breath with disgust "_mutation!_".

I like terms used by Eric Normand: calculations VS actions. Currently I like extreme purism most useful as thinking tool. When I have asked to help with some messy code piles with buggy / unpredictable behviour, I bite the bullet and describe / redesign roughly same system as pure functional style. On that form you can easily spot fundamental errors. After that you can fix them using more or less FPish style. I have couple of wins where nobody else has been able to make sense about the code (even tough code is written completely by themselves) but I can systematically apply this method and solve problem. So this is my current day job superpower 😃 (yea yea no silver bullet I know...)

@Niko Autio From a skim I did not understand why you believe such a feature would help make programming simpler/easier in any way. You're saying side-effects should just be expressed as implicit parameters? If so, I don't think that would make programs easier to understand. You'd quickly be passing huge messes of parameters around, and your programs would be fragile because they'd break when the compiler can't figure out how to thread everything together.

@Nick Smith Reasoning about side effects is kind of second thought. Primarily it's meant to be able to write side-effect like code while it's actually pure. Idea is motivated by experience I have got when doing purish F#: ~every time you get new random business requirement ("hey when A is X we want completely unrelated B to be Y") you have to refactor part of your application. Kind of "renormalize" it. Somebody might say that this idea make easier to take technical debt which gives you more productivity but indeed if you take too much of... I imagine that outcome could finally be something like that if you have zero tooling it just give somekind of "side effect" ability and if you can live with them in JS you should be able to live with those things too. And in opposite direction where compiler/IDE can visualize parameters well it's just regular pure code only with less writing. So I don't know is this any game changer but I would like to try programming with such thing myself.